From: 
Sent: 
To: 

Subject: 


manser [manser@charybdis] 
Wednesday, August 16, 1995 4:12 PM 
craig; hayes 

RE: Zeus summary/Friday 8/12/95 


Ray/Craig, 


Do we have an understanding of cache misses vs cache size - per the below? 
Or are the misses outside of (fast) cache into (slow) memory? 


Steve 


From: Graham Y. Mostyn on Tue, Aug 15, 1995 1:05 PM 
Subject: Zeus summary/ Friday 8/12/95 
To: zeus 

Cc: graham; mouss 


Minutes of the Zeus summary meeting, reporting the activities of the technology, 
architecture and marketing sub-groups. 
Friday 8/12/95 

Attendees: bill gmo graham hayes tbr todd 

TECHNOLOGY GROUP 

* Bill presented Zeus die cost data as a function of logic nets and memory size. 

He had studied the relationship between the number of logic nets, the total and average 
wire lengths, and the available vs. actual area used for wiring on Euterpe and Mnemo. 
He noted that for both chips, the measure of routing efficiency (available/actual wiring 
area) was similar; 1.8 and 2.2 respectively. 

Based on the assumption that Zeus, like Euterpe and Mnemo, would also be wire -limited, he 
projected logic area as a function of net number, taking the cases where the average wire 
length is fixed, and where the average wire length is proportional to the net number. 

Adding area for memory size and pads, he applied Murphy yield calculations and 
representative 8 inch CMOS wafer costs to compute die cost . 

* Bill also presented costs attributable to cooling. 

He plotted the heat sink and fan costs required for the chip and power supply (but not the 
cost of the supply itself) . 

This suggested bounds of 30c to 50c per watt over the range 15W to 120W. 

* Next step: Pursue package costs. We will then have a quite complete cost -analysis 
algorithm . 

ARCHITECTURE GROUP 

The action item at the last meeting was to understand the low utilization of a cylinder in 
booting Unix. 

* Ray Hayes presented his work on investigating how the compiler could reduce the number 
of stalls. 

He concluded that the compiler could not contribute to the problem very much, other than 
reducing issue restrictions - not very significant, compared to D and I cache initiated 
stalls. 

2 out of 3 cycles are stalls in Euterpe's architecture; 50 million stalls are associated 
with 21 million instructions. 

(From last week's minutes, of the 50M, issue restrictions account for ~7M, while cache 
misses account for ~33M) . 
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* Tim pointed out that the current Euterpe multithreaded architecture has high cache 
penalties, but offers guaranteed throughput, important when interaction must occur between 
threads . 

He asked what should our metric be for Zeus, a different architecture? Instructions per 
cycle? We agreed that the benchmark will be clearer when we have isolated the main 
applications of interest. 

MARKETING GROUP 

Todd reported on the group's activities of the past week, 

* He had studied our competitors 1 activities from Microprocessor report and the Web. He 
noted that their publicized business plans were remarkably similar to ours, based upon 
addressing multimedia applications by adding DSP capability to their processors. 

Philips, for example, is developing a new processor core with VLIW architecture; 
specialized operations are being added for video compression and communications. He felt, 
in particular, that Intel could pose a threat by adding DSP functions slowly, step by 
step. He had also examined DEC, IBM and Intel. 

He pointed out that MicroUnity has the benefit of not being constrained by needing to 
include support for existing customers in new product offerings, however. 

* He emphasized the importance of selecting markets and developing an entry strategy for 
each; why would customers need the technology? The benefits must be apparent. 

* Next step: 

- Having already considered the PC, cablemodem and set top platforms, the group is 
analysing the attractiveness of additional platforms/applications, in particular, 
networking and communications. 

- They will also present a summary of competitive microprocessor performance/cost, 
alongside Zeus cost data obtained from the technology group. 


End included Message 


End Included Message 
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From: jack (Jack Wenstrand) 

Sent: Wednesday, August 16, 1995 2:30 PM 

To: zeus 

Cc: tony 

Subject: Re: Zeus summary/Friday 8/12/95 


> Date: Tue, 15 Aug 1995 13:02:23 -0700 

> From: graham (Graham Y. Mostyn) 
> 

> Minutes of the Zeus summary meeting, reporting the activities of the 

> technology, architecture and marketing sub-groups. 

> Friday 8/12/95 

* * * 

> ARCHITECTURE GROUP 

* * * 

> * Tim pointed out that the current Euterpe mult i- threaded architecture 

> has high cache penalties, but offers guaranteed throughput, important 

> when interaction must occur between threads. 

Monica Lam of Stanford present work at Hot Chips on "Hot compilers for hot chips" to 
address the the question "Are multiprocessors competitive to processors with high 
instruction- level parallelism?". In support of Tim's point, she emphasized that that 
performance improvements super- linear with processor count were readily achieved with 
multiple processors where coarse-grained parallelism was found because of additional 
cache, but that little speed-up could be achieved with multiple processors where fine- 
grained communication between threads was required. She mentioned the advantages of 
multi- threaded architectures for this class of applications. 

* * * 

> He asked what should our metric be for Zeus, a different architecture? 

> Instructions per cycle? We agreed that the benchmark will be clearer 

> when we have isolated the main applications of interest. 

* * * 

IPC, power, area, and clock all count... Also from Hot Chips, PowerPC presented a metric 
of 

SPECint92 


Power (W) * Size(mm2) 
Coincidently, the PPC S03el66 was at the top of the chart by this metric. 

I've passed on some scaling and cost information presented by Gordon Moore to Bill Herndon 
for the Technology group. 

- Jack 
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Subject: 


Sent: 

To: 

Cc: 


From: 


graham (Graham Y. Mostyn) 
Tuesday, August 15, 1995 3:02 PM 
zeus 

graham; mouss 

Zeus summary/Friday 8/12/95 


Minutes of the Zeus summary meeting, reporting the activities of the technology, 
architecture and marketing sub-groups. 
Friday 8/12/95 

Attendees: bill grao graham hayes tbr todd 
TECHNOLOGY GROUP 

* Bill presented Zeus die cost data as a function of logic nets and memory size . 

He had studied the relationship between the number of logic nets, the total and average 
wire lengths, and the available vs. actual area used for wiring on Euterpe and Mnerao. 
He noted that for both chips, the measure of routing efficiency (available /actual wiring 
area) was similar; 1.8 and 2.2 respectively. 

Based on the assumption that Zeus, like Euterpe and Mnemo, would also be wire- limited, he 
projected logic area as a function of net number, taking the cases where the average wire 
length is fixed, and where the average wire length is proportional to the net number. 

Adding area for memory size and pads, he applied Murphy yield calculations and 
representative 8 inch CMOS wafer costs to compute die cost. 

* Bill also presented costs attributable to cooling. 

He plotted the heat sink and fan costs required for the chip and power supply (but not the 
cost of the supply itself) . 

This suggested bounds of 3 0c to 50c per watt over the range 15W to 120W. 

* Next step: Pursue package costs. We will then have a quite complete cost-analysis 
algorithm. 

ARCHITECTURE GROUP 

The action item at the last meeting was to understand the low utilization of a cylinder in 
booting Unix. 

* Ray Hayes presented his work on investigating how the compiler could reduce the number 
of stalls. 

He concluded that the compiler could not contribute to the problem very much, other than 
reducing issue restrictions - not very significant, compared to D and I cache initiated 
stalls . 

2 out of 3 cycles are stalls in Euterpe l s architecture; 50 million stalls are associated 
with 21 million instructions. 

(From last week's minutes, of the 50M, issue restrictions account for ~7M, while cache 
misses account for ~33M) . 

* Tim pointed out that the current Euterpe multithreaded architecture has high cache 
penalties, but offers guaranteed throughput, important when interaction must occur between 
threads . 

He asked what should our metric be for Zeus, a different architecture? Instructions per 
cycle? We agreed that the benchmark will be clearer when we have isolated the main 
applications of interest. 

MARKETING GROUP 

Todd reported on the group's activities of the past week. 
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* He had studied our competitors' activities from Microprocessor report and the Web- He 
noted that their publicized business plans were remarkably similar to ours, based upon 
addressing multimedia applications by adding DSP capability to their processors. 

Philips, for example, is developing a new processor core with VLIW architecture; 
specialized operations are being added for video compression and communications. He felt, 
in particular, that Intel could pose a threat by adding DSP functions slowly, step by 
step. He had also examined DEC, IBM and Intel. 

He pointed out that MicroUnity has the benefit of not being constrained by needing to 
include support for existing customers in new product offerings, however. 

* He emphasized the importance of selecting markets and developing an entry strategy for 
each; why would customers need the technology? The benefits must be apparent. 

* Next step: 

- Having already considered the PC, cablemodem and set top platforms, the group is 
analysing the attractiveness of additional platforms/applications, in particular, 
networking and communications. 

- They will also present a summary of competitive microprocessor performance/cost, 
alongside Zeus cost data obtained from the technology group . 


End Included Message 


End Included Message 
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From: hopper (Mark Hofmann) 

Sent: Tuesday, August 15, 1995 8:01 AM 

To: al (Albert Matthews); geert {Geert Rosseel); paulp (Paul Poenisch); anh (Anh Ngo); jack (Jack 

Wenstrand); rich (Rich McCauiey); ong (Warren R. Ong); mouss (John Moussouris); tony 
(Tony Stelliga); manser (Steve Manser); drew; mudge (john mudge); cadettes; fung (Fung 
Chen); kumar; tomb; yao (Henry Yao); rip (Rajiv Patel); to (To Do); ted (Ted Chen); ky (K.Y. 
Ramanujam); Hang; hoov (Bill Hooven); trancy (Trancy Tsao); linden (Linden Critchlow); 
anderson 

Cc: alves (Maria Alves); graham (Graham Y. Mostyn); dane (Dane Snow); yves (Jean-Yves 

Michel); ras (Bob Sutherland); tomho (Tom Ho); michael (Chris Michael); solo (John 
Campbell); tbr (Tim B. Robinson); efelias (Eldred Felias); vikki (Vikki Vu); orlando (Orlando 
Hernando); mikew (Mike Wageman); dtacmo (Dominador Tacmo); euterpe 

Subject: Layout Review: 15 Aug 95 


Here are notes from the informal meeting to discuss 

PISil / Contact Ped fix up + additional discussion with Al and Fung 

* Geert is preparing a similar list as last time of cells that need 
Plsil/contped repair. This time we'll work on the large cells first. 

* Goal is to fix these cells up by Friday 18 Aug so that we may start the 
verification process for a target fracture last week of August and 
ship tapes 5 September 

* Layer Poly on down will be locked from editing. PISil and up (including 
SDEC) may be edited. Be careful about undoing SDEC changes and about 
running LVS on changed cells. If you can check you cells in by 7p each 
day, Dave will automatically release them and Solo will run the necessary 
DRC and LVS checks. 

* In the meeting we came up with an ordering of fix-ups. Subsequent 
discussion with Al and Fung modified this slightly. Here is the 
order for fixing up layouts: 

BASIC IDEA: Contact pedestal crossing Polyl-Silicide edges is to be 
avoided if at all possible 

Best : Leave 3udr PISil collar around contped 
Leave 2udr PISil collar around contped 
Use a 0.7u butting contact 
Use a 0.5u butting contact 

Leave ludr PISil collar around contped 
Worst: Leave Oudr PISil collar around contped (coincident edge) 

Notel: these rules apply on a per edge basis. It is likely that there will 
be more than 1 edge which is affected. It is then necessary to make 
some trade-off between the above strategies for all the edges 
of the cont ped polygon in aggregate. 

Note2: If you cannot avoid crossing PISil then try to make the contact 

pedestal as wide as possible (0.7u) at the point of crossing and try 
to extend contped beyond the PISil edge as far as possible (0.85u) . 

-hopper 
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From: manser [manser@charybdis] 

Sent: Tuesday, August 1 5, 1 995 11:35 AM 

To: geert; john mudge; Lisa Robinson; tbr 

Subject: RE: Still waiting for .. 


Johnny, 

Your help would be greatly appreciated here. Also, I think we should dedicate some time 
on Friday of this week to review the test plan for Cronus and Euterpe given Mark W's 
departure and the accelerated schedule. 

Can you have 2-3 slides to review your organizations plan and schedule for the test of 
both of these parts? 

Alternately, we may want to expand the attendence this Friday. Comments Geert, Tim, Lisa? 
Steve 


From: Lisa Robinson on Mon, Aug 14, 1995 11:48 AM 
Subject: Still waiting for 
To : mudge 
Cc : manser 


Johnny. 

I am still awaiting your input to the euterpe and cronus schedules for wafer test. 

I have had a stab at the euterpe flow and clearly some tasks apply both to euterpe and 
cronus. (I've put a copy in you mailbox) . 

The test program development (jeffm task 88) will move in if the cronus tapeout is earlier 
than currrently shown. 

I don't have the cronus DUT board schedule and it doesn't show on Pattie's schedule as 
work in progress. 

We do continue to hold a schedule review each Wednesday at 10am and tactical reviews at 
10am on Monday and Friday. 

Lisa R. 
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Subject: 


From; 
Sent: 
To: 
Cc: 


tbr 

Tuesday, August 15, 1995 1:23 AM 
wampler (Kurt Wampler) 
hopper 

Euterpe hand route 


Kurt Wampler wrote (on Mori Aug 14) : 
Hi, Tim - 

I've completed hand- routing of the latest Euterpe route. The dff is: 

/n/gamorra/s3/wampler/eurip/chip_euterpe- iter .dff 
There's also a netcap file: 

/n/gamorra/ s3/ wampler /eurip/chip_euterpe- i ter.net cap 

Besides completing all of the disconnects, I went through the list of 
timing violations and made wiring improvements on every path that failed 
cycle time. With any luck there will be very few or no additional wire 
mods needed. At your convenience, could you re-run topt and see how close 
this one comes to meeting the timing goal? If there are just a handful of 
wires, I may be able to fix them tonight... 

I have copied the .dff back to the snapshot (having saved the untouched version) because I 
have a Makefile rule setup there to make the report. It's running now. 


Tim 


Exhibit C17 


From: 
Sent: 
To: 

Subject: 


tbr 

Tuesday, August 15, 1995 1:09 AM 
graham (Graham Y. Mostyn) 
Could you assist? Thanks. 


Graham Y. Mostyn wrote (on Mon Aug 14) : 


Tim, I've finished a first draft of Friday's 
Zeus meeting, but I don't feel too confident on 
my report of the architecture discussion! 

Could you check over that section below, before I 
distribute, please? {I also forwarded it to Gmo 
for comment) 

Thanks - Graham. 


ARCHITECTURE GROUP 

Gmo presented his work on investigating how the compiler 
could reduce the number of stalls in booting Unix. 
(2 cycles are lost per stall in Euterpe's architecture.) 
Of 21 million instructions, there are 13 million stalls. 

I think "stall" should be "store" here. 

He concluded that the compiler could not contribute 
to the problem very much, other than reducing issue 
restrictions - not very significant, compared to 
D and I cache initiated stalls. 

Tim pointed out that the current Euterpe multithreaded 
architecture has high cache penalties, but offers 
guaranteed throughput, important when interaction 
must occur between threads. The appropriate benchmark is 
instructions per cycle. 

He asked what should our metric be for Zeus, a different 
architecture? We agreed that this will be clearer when we 
have isolated the main applications of interest. 

* Next step 

*not clear on this* 

Sorry, I was only able to be in the meeting so briefly. I don't recall what was discussed 
here for the next step. 


Tim 
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From: 
Sent: 
To: 


Cc: 

Subject: 


geert (Geert Rosseel) 

Tuesday, August 15, 1995 12:08 AM 

dane; dtacmo; efefias; geert; graham; hessam; hopper; mikew; ong; orlando; rich; tau; 
vanthof, vikki; wampler, yves 
jack; manser 
Euterpe Layouts : PASS II 


HI, 


It looks like the.SDEC fixes are almost completely in and we have some time before tape- 
out to fix the next set of DRVs. 

So, we'll have another pass at all the cells fixing up the silicide- contact pedestal 
interface error. There will be a meeting tomorrow (tuesday) at 10:00 in the multi-media 
room to discuss this error. 

The plan is the same as before . . I'll use the same list of cells as before and everyone 
can pick their favorite block starting from the top. 

Solo is running all blocks overnight . . so the results should be in by Tuesday morning. 

-solo/plsil/compass/* .err 


Geert 
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From: vanthof (vant) 

Sent: Monday, August 14, 1995 10:44 PM 

To: Mark Hofmann 

Cc: vanthof (Dave Van't Hof); torn (Tom Laidig); geert (Geert Rosseel) 

Subject: Re: tat metal adjustment 


Mark Hofmann writes: 
> 

>They say a little knowledge is a dangerous thing. I'm dangerous... 

>Umm. .. okay so we remove the shrink of contact ped and vias . Then we 

>fix up (either by hand or automagically) contped and vias. _Then_ do we 

>maybe want to shrink any wide contact ped and via that has not been "f ixed-up"? 

> (not sure how we determine that . . . ) 

> 

> -hopper 


Well, I would like to see us fix all 'wide' vias on all via layers, including contped. If 
we can achieve that, the via shrinking can be removed. If via shrinking can be removed, 
then not only is fracturing simpler and FASTER, but so are drc runs... 

That would remove 5 rather computationally intense steps from the tapeout and drc process. 
We may even completely compensate for the additional time introduced by the sdec and plsil 
synthesis. , . 

Dave 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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Subject: 


From: 
Sent: 
To: 

Cc: 


hopper (Mark Hofmann) 
Monday, August 14, 1995 3:17 PM 
vant 

torn (Tom Laidig); geert (Geert Rosseel); vanthof (Dave Van't Hot) 
Re: fat metal adjustment 


vant writes : 


I have a question. I now go through elaborate work to shrink wide contact 
pedestals and vias. Since we are going to fix up plsil and contact overlaps, 
and allow min spacings of 8 udrs (after biasing min x min contpeds) , this 
causes all sort of havoc with the big contped adjustments. 

I would like to remove all wide contped and via adjustment from the tapeout 
flow. This does reduce run times of the tapeout a bit (as well as drcs) . 


They say a little knowledge is a dangerous thing. I'm dangerous... 

Umm... okay so we remove the shrink of contact ped and vias. Then we fix up (either by 
hand or automagically) contped and vias . _Then_ do we maybe want to shrink any wide 
contact ped and via that has not been "f ixed-up" ? 
(not sure how we determine that...) 


Comments? 
Dave 


-hopper 
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From: 
Sent: 
To: 

Subject: 


graham (Graham Y. Mostyn) 
Monday, August 14, 1995 9:47 PM 
tbr 

Could you assist? Thanks. 


Tim, I've finished a first draft of Friday's Zeus meeting, but I don't feel too confident 
on my report of the architecture discussion! 

Could you check over that section below, before I distribute, please? (I also forwarded it 
to Gmo for comment) 

Thanks - Graham. 


ARCHITECTURE GROUP 

Gmo presented his work on investigating how the compiler could reduce the number of stalls 
in booting Unix. 

(2 cycles are lost per stall in Euterpe's architecture.) Of 21 million instructions, there 
are 13 million stalls. 

He concluded that the compiler could not contribute to the problem very much, other than 
reducing issue restrictions - not very significant, compared to D and I cache initiated 
stalls. 

Tim pointed out that the current Euterpe multithreaded architecture has high cache 
penalties, but offers guaranteed throughput, important when interaction must occur between 
threads. The appropriate benchmark is instructions per cycle. 

He asked what should our metric be for Zeus, a different architecture? We agreed that 
this will be clearer when we have isolated the main applications of interest. 

* Next step 

*not clear on this* 
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Sent: 
To: 

Cc: 


Subject: 


From: 


graham (Graham Y. Mostyn) 
Monday, August 14, 1995 9:25 PM 
manser@charybdis 

geert; graham; hopper; tbr; lisar; mudge 
RE: Tape Out (part 1) 


Great idea ! 

The engineers in my group that have designed cells within Euterpe are: 

- Jean-Yves Michel 

- Rich McCauley 

- Dane Snow 

Regards , Graham . 


> From manser@charybdis Mon Aug 14 18:47:55 1995 

> Date: 14 Aug 1995 18:45:36 -0800 

> From: "manser" <manser@charybdis> 

> Subject: RE: Tape Out (part 1) 

> To: "geert" <geert@gaea>, "graham" <graham@gaea> , "hopper" <hopper@gaea> , 

> "lisar" <lisar@gaea>, "mudge" <mudge@gaea> , 

> "Tim B. Robinson" <tbr@charybdis> 

> Content-Length: 811 

> Tim, Geert, Hopper, Johnny, Graham, Lisa, 
> 

> I was hoping to get a list of folks from you (Hopper) , Geert, and 

> others tomorrow to have a pizza party. Leave work around 4pm, grab 

> some pizza and beer and relax, celebrate, etc. Nothing fancy - just a 

> breather and to recognize good progress. 
> 

> I was thinking 12-18 people... who would you invite? 


> ps: Let me know ASAP so we can size up the number of people. Also, 

> let's keep it confidential until we have the list finalized. 


> From: Tim B. Robinson on Mon, Aug 14, 1995 4:23 PM 

> Subject: Tape Out (part 1) 

> To: euterpe 
> 

> 

> We have today shipped tapes for the first 14 layers (the baseplate) 

> for euterpe. 

> 

> Thanks to everyone involved for a huge effort in making this happen. 


> 


Steve 


> 


> 


> 


> 


Tim 


> 


> 


> 
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From: 
Sent: 
To: 

Subject: 


manser [manser@charybdis] 

Monday, August 14, 1995 9:46 PM 

geert; graham; hopper; lisar; mudge; Tim B. Robinson 

RE: Tape Out (parti) 


Tim, Geert, Hopper, Johnny/ Graham, Lisa, 

I was hoping to get a list of folks from you (Hopper) , Geert, and others tomorrow to have 
a pizza party. Leave work around 4pm, grab some pizza and beer and relax, celebrate, etc. 
Nothing fancy - just a breather and to recognize good progress. 

I was thinking 12-18 people... who would you invite? 


pst Let me know ASAP so we can size up the number of people. Also, let's keep it 
confidential until we have the list finalized. 


From: Tim B. Robinson on Mon, Aug 14, 1995 4:23 PM 
Subject: Tape Out (part 1} 
To: euterpe 


We have today shipped tapes for the first 14 layers (the baseplate) for euterpe. 
Thanks to everyone involved for a huge effort in making this happen. 


Steve 


Tim 
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From: vanthof (vant) 

Sent: Monday, August 14, 1995 7:46 PM 

To: torn (Tom Laidig); hopper (Mark Hofmann); geert (Geert Rosseel) 

Cc: vanthof (Dave Van't Hof) 

Subject: fat metal adjustment 


I have a question. I now go through elaborate work to shrink wide contact pedestals and 
vias. Since we are going to fix up plsil and contact overlaps, and allow min spacings of 
8 udrs (after biasing min x min contpeds) , this causes all sort of havoc with the big 
contped adjustments. 

I would like to remove all wide contped and via adjustment from the tapeout flow. This 
does reduce run times of the tapeout a bit (as well as drcs) . 

Comments? 
Dave 

Dave Van't Hof MicroOnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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From: tbr (Tim B. Robinson) 

Sent: Monday, August 14, 1995 6:21 PM 

To: euterpe 

Subject: Tape Out (part 1 ) 


We have today shipped tapes for the first 14 layers (the baseplate) for euterpe. 

Thanks to everyone involved for a huge effort in making this happen. 

Tim 
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From: vanthof (vant) 

Sent: Monday, August 14, 1995 3:59 PM 

To: hardheads 

Cc: vanthof (Dave Van't Hof) 

Subject: euterpe lower layers 


More lower layer edits have been occuring for cells that are used in euterpe. The edits 
consist of adding/removing actives and polys . 

This is not allowed as the lower layers are frozen for tapeout. 

Please refrain from modifying the following layers: 

buried, nwell, buried contact, emitter, collector plug, base polyl, 
base contact, n+active, p+active, depletion implant, natural implant, 
p+polyl, n+polyl, poly resistor, diffused resistor, undoped polyl 


Dave 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof®microunity . com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . ■ The Tick to Thrackazog 
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From: solo (John Campbell) 

Sent: Monday, August 14, 1995 1:38 PM 

To: Lisa Robinson 

Cc: brianl (Brian Lee); geert (Geert Rosseel); wingard (Drew Wingard); tbr (Tim B. Robinson) 

Subject: Re: atlas build 


as Lisa Robinson was saying 


Brian Lee wrote (on Mon Aug 14) ; 
John Campbell writes : 
brianl 

lisar has suggested that i try and build atlas and you are the one who 
knows what the magic dust must be made of . 

Let's just be clear about what we are doing here. John is building the ..cronus atlas 
and chaos trees. They shoukd be built as chip and thay ..will be used for cronus tapeout, 

I think that having atias/chaos -> /u/chip/chaos is fine for now. Though, 
realize that you are then affected by ongoing releases in /u/chip/chaos. 
Are you going to be building chaos also? If so, perhaps you can point to 
it instead. 

I absolutely disagree. Chaos should be built too. 
Brian L. 

Lisa R. 

so i will build a script that checks out and builds chaos followed by a build of atlas, 
will put them on s52/ snapshot 


regards , 

solo a.k.a. John Campbell x516 
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From: lisar (Lisa Robinson) 

Sent: Monday, August 14, 1995 1 :35 PM 

To: brianl (Brian Lee); solo 

Cc: geert; wingard; tbr 

Subject: Re: atlas build 


Brian Lee wrote (on Mon Aug 14) : 
John Campbell writes: 
brianl 

lisar has suggested that i try and build atlas and you are the one who 
knows what the magic dust must be made of. 

Let's just be clear about what we are doing here. John is building the cronus atlas and 
chaos trees. They shoukd be built as chip and thay will be used for cronus tapeout . 

can you advise me as to how to make sure we have the right amount of 
chaos and altlas mixed together to make this happen properly. 

what i think we did back in april was: 
getbom of atlas. 

"In -s . . /atlas" ; 

"In -s . . /tools" ; 

"In -s ../technology"; 

"In -s /u/chip/ chaos" ; 

i am not sure whether we has a link to ../chaos, i don't think so. 

I think that having atlas/chaos -> /u/chip/chaos is fine for now. Though, 
realize that you are then affected by ongoing releases in /u/chip/chaos. 
Are you going to be building chaos also? if so, perhaps you can point to 
it instead. 

I absolutely disagree. Chaos should be built too. 

jand " . . " contaned links to /u/chip/chaos /u/chip/altlas, tools, and technology 
| then gmake 

Scratch the /u/chip/altlas link; otherwise, everything looks fine to me. 
Good luck, 

Brian L. 

Lisa R. 


Exhibit C17 


Page 20 of 1 


Subject: 


Sent: 
To: 

Cc: 


From: 


torn (Tom Laidig [tau]) 

Monday, August 14, 1995 12:34 PM 

Kurt Wampler 

hopper (Mark Hofmann); tau; tbr (Tim B. Robinson); vanthof (Dave Van't Hof) 
RE: fracture crash 


Kurt Wampler writes: 
Tom Laidig writes : 


>Could we start a verification that a tapeout of the layouts in 
>/n/cyclops/sl/dracjobs/immlayouts2 would produce the same 010-140 
>pat terns that we have now? This would be just a form of xor- check, I 
> think. No fracture output or DRCs needed. 
> 

>I _think_ our current tapes are OK, but as I've mentioned in other 
>messages, I was a bit late getting the script in place to verify that 
>lower layers hadn't been accidentally changed, and I'm not certain 
>what might have been in the snapshot when the fracture flow was 
>flattening its input. 

I can start this up. What vlsi.boo file should be used for this 
comparison? I don't find one in that directory, . . 

No, there is no .boo file there; it is a single directory that contains all layouts. So 
you can either create a .boo file somewhere or run the fracture with the "-p 
/n/cyclops/sl/dracjobs/immlayouts2 • option, whichever is easier. 

I think that, in the future, we'll continue to do staged tapeouts, and we'll be doing the 
early fractures at least from a single directory that contains copies of all layouts 
(probably the same one that the final DRC created) . So you might want to think about 
setting things up so that's easy to do. 
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Subject: 


Sent: 
To: 

Cc: 


From: 


warn pier (Kurt Wampler) 

Monday, August 14, 1995 12:00 PM 

torn 

hopper; tau; tbr; vanthof 
RE: fracture crash 


Tom Laidig writes: 


>Could we start a verification that a tapeout of the layouts in 
> /n/ cyclops/ si /dracjobs/immlayouts2 would produce the same 010-140 
>pat terns that we have now? This would be just a form of xor- check, I 
>think. No fracture output or DRCs needed. 


>I _think__ our current tapes are OK, but as I've mentioned in other 
messages , I was a bit late getting the script in place to verify that 
>lower layers hadn't been accidentally changed, and I'm not certain what 
>might have been in the snapshot when the fracture flow was flattening 
>its input. 

I can start this up. What vlsi.boo file should be used for this 
comparison? I don't find one in that directory... 


> 


- Kurt 


Exhibit C17 


Page 22 of 14 


Sent: 
To: 

Cc: 


Subject: 


From: 


hopper (Mark Hofmann) 
Monday, August 14, 1995 4:57 AM 
Tom Lafdig [tau] 

wampler (Kurt Wampler); tau; vanthof (Dave Van't Hof); tbr (Tim B. Robinson) 
RE: fracture crash 


Tom Laidig [tau] writes: 

Could we start a verification that a tapeout of the layouts in 
/n/cyclops/sl/dracjobs/immlayouts2 would produce the same 010-140 
patterns that we have now? This would be just a form of xor~ check, I 
think. No fracture output or DRCs needed. 

I _think_ our current tapes are OK, but as I've mentioned in other 
messages, I was a bit late getting the script in place to verify that 
lower layers hadn't been accidentally changed, and I'm not certain what 
might have been in the snapshot when the fracture flow was flattening 
its input. 

Good idea . 


-hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


torn (Tom Laidig [tau]) 

Monday, August 14, 1995 11:55 AM 

wampler (Kurt Wampler) 

tau; vanthof (Dave Van't Hof); hopper (Mark Hofmann); tbr (Tim B. Robinson) 
RE: fracture crash 


Tom Laidig [tau] writes: 

Also, we need to prepare for a final fracture run where we verify that 
a lower- layer fracture now would produce the same tapes we sent 
yesterday (or some such combination of verb tenses) . I'd like to fire 
up such a comparison now for layers 010-110. 

Could we start a verification that a tapeout of the layouts in 

/n/cyclops/sl/dracjobs/immlayouts2 would produce the same 010-14 0 patterns that we have 
now? This would be just a form of xor- check, I think. No fracture output or DRCs needed. 

I _think_ our current tapes are OK, but as I've mentioned in other messages, I was a bit 
late getting the script in place to verify that lower layers hadn't been accidentally 
changed, and I'm not certain what might have been in the snapshot when the fracture flow 
was flattening its input . 


1 \. 
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From: manser [manser@charybdis] 

Sent: Monday, August 14, 1995 11:27 AM 

To: doi@charybdis; gmo@charybdis; guarino@charybdis; iimura@charybdis; jeffm@charybdis; 

Lisa Robinson 

Cc*. euterpe@charybdis; manser@charybdis; software@charybdis; sysadm@charybdis 

Subject: RE: OSF1 kernel boot test: PASSED 


Great news! Keep up the great work! 
Steve 


From: Lisa Robinson on Mon, Aug 14, 1995 7:38 AM 
Subject: OSF1 kernel boot test: PASSED 
To: doi; gmo; guarino; iimura; jeffm 
Cc : euterpe; manser; software; sysadm 


The 0SF1 kernel boot test has just PASSED after running continuously for 8 days. 

Yeah! 

Lisa R. 

Here are the messages printed during its execution. 

Terp boot: memory from 0x14 0000 to 0x800000 

Kernel dynamic virtual space from Oxfff 1000 000 000 000 

to Oxfff 1000004000000 . 

OSF1 Release 1.1 (oscl.l) ; Fri Jul 14 15:41:16 PDT 1995; HWSIM (pippin) 
physical memory = 8-00 megabytes, 
available memory =4.6 megabytes. 

using 102 buffers containing 0.79 megabytes (10%) of memory 
hdO : disk unit is not defined, 
hdl: disk unit is not defined. 
hd2 : disk unit is not defined. 
hd3 ; disk unit is not defined. 

mtprobe: 4 simulated tapes configured, terp.mt? 
OSF1 kernel boot test : PASSED 

We are now about 1/5 the way to booting to single user prompt. Note that the configured 
simuator used was gave lower performance than the simulator that will be used for the full 
OSF run. The full run should take about 10 days. 

Here is a cut from previous posted mail 

We had a short discussion about the progress of the shortened OSF test that is being run 
on the HW simulator. 
-- cut- - 

Once this test has run, the following steps have been accomplished. 

o kernel data structures will have been initialized 
o the v probe 1 steps have been faked out . 
o all kernel memory is setup 

- dynamic pages for text 
buffer caches 

The above steps are estimated to take about 30 milliseconds wall clock time. 
What remains to get us to a single user prompt? 
o mach init 
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o init 

o exec of a shell 

The total wall clock time estimate to do the entire boot and arrive at a single user 
prompt is about 150 milliseconds (not accounting for disk I/O) . 
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From: lisar (Lisa Robinson) 

Sent: Monday, August 14, 1 995 9:38 AM 

To: doi; gmo; guarino; iimura; jeffm 

Cc: euterpe; manser; software; sysadm 

Subject: OSF1 kernel boot test: PASSED 


The OSF1 kernel boot test has just PASSED after running continuously for 8 days. 

Yeah! 

Lisa R. 

Here are the messages printed during its execution. 

Terp boot: memory from 0x140000 to 0x800000 

Kernel dynamic virtual space from Oxfff 1000000000000 

to 0xfffl000004000000. 

OSF1 Release 1.1 (oscl.l); Fri Jul 14 15:41:16 PDT 1995; HWSIM (pippin) 
physical memory » 8.00 megabytes, 
available memory = 4.6 megabytes. 

using 102 buffers containing 0.79 megabytes (10%) of memory 

hdO: disk unit is not defined. 

hdl: disk unit is not defined. 

hd2 : disk unit is not defined. 

hd3 : disk unit is not defined. 

mtprobe: 4 simulated tapes configured, terp.mt? 

OSF1 kernel boot test: PASSED 

We are now about 1/5 the way to booting to single user prompt. Note that the configured 
simuator used was gave lower performance than the simulator that will be used for the full 
OSF run. The full run should take about 10 days. 

Here is a cut from previous posted mail 

We had a short discussion about the progress of the shortened OSF test that is being run 
on the HW simulator. 
-- cut- - 

Once this test has run, the following steps have been accomplished. 

o kernel data structures will have been initialized 
o the "probe 7 steps have been faked out. 
o all kernel memory is setup 

dynamic pages for text 

buffer caches 

The above steps are estimated to take about 30 milliseconds wall clock time. 

What remains to get us to a single user prompt? 

o mach_init 
o init 

o exec of a shell 

The total wall clock time estimate to do the entire boot and arrive at a single user 
prompt is about 15 0 milliseconds (not accounting for disk I/O) . 
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From: lisar (Lisa Robinson) 

Sent: Monday, August 14, 1995 9:38 AM 

To: doi; gmo; guarino; iimura; jeffm 

Cc: euterpe; manser; software; sysadm 

Subject: OSF1 kernel boot test PASSED 


The OSF1 kernel boot test has just PASSED after running continuously for 8 days. 

Yeah! 

Lisa R. 

Here are the messages printed during its execution. 

Terp boot: memory from 0x14 0000 to 0x80 000 0 

Kernel dynamic virtual space from Oxfff 1000000000000 

to 0xfffl000004000000. 

OSF1 Release 1.1 (oscl.l); Fri Jul 14 15:41:16 PDT 1995; HWSIM (pippin) 
physical memory = 8.00 megabytes, 
available memory = 4.6 megabytes . 

using 102 buffers containing 0.79 megabytes (10%) of memory 
hdO: disk unit is not defined, 
hdl: disk unit is not defined. 
hd2 : disk unit is not defined. 
hd3 ; disk unit is not defined. 

mtprobe: 4 simulated tapes configured, terp.mt? 
OSF1 kernel boot test: PASSED 

We are now about 1/5 the way to booting to single user prompt. Note that the configured 
simuator used was gave lower performance than the simulator that will be used for the full 
OSF run. The full run should take about 10 days. 

Here is a cut from previous posted mail 

We had a short discussion about the progress of the shortened OSF test that is being run 
on the HW simulator. 
- - cut - - 

Once this test has run, the following steps have been accomplished. 

o kernel data structures will have been initialized 
o the "probe 1 steps have been faked out . 
o all kernel memory is setup 

dynamic pages for text 

buffer caches 

The above steps are estimated to take about 30 milliseconds wall clock time. 

What remains to get us to a single user prompt? 

o mach_init 
o init 

o exec of a shell 

The total wall clock time estimate to do the entire boot and arrive at a single user 
prompt is about 150 milliseconds (not accounting for disk I/O) . 
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From: Mark Hofmann [hopper@gaea.microunity.com] 

Sent: Monday, August 14, 1995 1:31 AM 

To: vant 

Cc: geert@microunity.com; Lisa Robinson; Tim B. Robinson; Drew Wingard; Dave Van't Hof 

Subject: Re: A Cronus baseplate ready for DRC .. 


vant writes: 

The problem with drc jobs dieing is not with the flow, but with dracula. 
There appears to be a bug in dracula that causes the SIZE module to bomb 
out . I ran a test on hestia with the latest version of dracula and it 
worked on a block that used to fail. However, when I had tacmo try it 
out, his whole environment was messed up and no dracula binaries were found. 

I can have some one else try a test tomorrow to help track down the 
environment problem. If it does work, then I can have a couple of machines 
upgraded with this new version. 

I'm leary about installing this new version of dracula just as we are 
trying to tapeout euterpe. There could be some subtle differences in the 
tool which will cause all kinds of problems when we least need them. 

Dave, 

If you need a guinea pig to start off a run, I can try out my environment. 

- thanks , 
hopper 
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From; 
Sent: 
To: 
Cc: 


Subject: 


hopper (Mark Hofmann) 
Monday, August 14, 1995 1:31 AM 
vant 

geert@microunity.com; lisar (Lisa Robinson); tbr (Tim B. Robinson); wingard (Drew Wingard); 

vanthof (Dave Van't Hot) 

Re: A Cronus baseplate ready for DRC 


vant writes : 

The problem with drc jobs dieing is not with the flow, but with dracula. 
There appears to be a bug in dracula that causes the SIZE module to bomb 
out . I ran a test on hestia with the latest version of dracula and it 
worked on a block that used to fail. However, when I had tacmo try it 
out, his whole environment was messed up and no dracula binaries were found. 

I can have some one else try a test tomorrow to help track down the 
environment problem. If it does work, then I can have a couple of machines 
upgraded with this new version. 

I'm leary about installing this new version of dracula just as we are 
trying to tapeout euterpe. There could be some subtle differences in the 
tool which will cause all kinds of problems when we least need them. 


If you need a guinea pig to start off a run, I can try out my environment. 


Dave, 


- thanks , 
hopper 
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Subject: 


Sent: 
To: 

Cc: 


From: 


vanthof (vant) 

Monday, August 14, 1995 12:12 AM 
Geert Rosseel 

hopper (Mark Hofmann); lisar (Lisa Robinson); tbr (Tim B. Robinson); wingard (Drew 
Wingard); vanthof (Dave Van't Hof) 
Re: A Cronus baseplate ready for DRC .. 


Geert Rosseel writes: 


> 


> Hi, 


> 


> I think I have a baseplate ready for toplevel DRC. I still need to do 
>some more work on clock connections, but most of it is there. 

> 

> I know the CSM flow still dies on a couple of large blocks ( I also 
>know that Dave is very busy . . ) . 

> 

> I'd like to try a toplevel DRC as soon as possible to see how long it 
>takes and to find algorithmicly generated DRV's. 

> 

> Can someone (maybe someone else than Dave) have a look at the flow ? 
> 

> with some luck, we should be able to run an LVS shorts test by the end 
>of the week. 

> 

> Geert 


The problem with drc jobs dieing is not with the flow, but with dracula. 
There appears to be a bug in dracula that causes the SIZE module to bomb out. I ran a 
test on hestia with the latest version of dracula and it worked on a block that used to 
fail. However, when I had tacmo try it out, his whole environment was messed up and no 
dracula binaries were found. 

I can have some one else try a test tomorrow to help track down the environment problem. 
If it does work, then I can have a couple of machines upgraded with this new version. 

I'm leary about installing this new version of dracula just as we are trying to tapeout 
euterpe. There could be some subtle differences in the tool which will cause all kinds of 
problems when we least need them. 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender' I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 


Dave 
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Sent: 

To: 

Cc: 


Subject: 


From: 


vanthof (vant) 

Monday, August 14, 1995 12:12 AM 
Geert Rosseel 

hopper (Mark Hofmann); lisar (Lisa Robinson); tbr (Tim B. Robinson); wingard (Drew 
Wingard); vanthof (Dave Van't Hof) 
Re: A Cronus baseplate ready for DRC .. 


Geert Rosseel writes: 


> Hi, 


> I think I have a baseplate ready for toplevel DRC. I still need to do 
>some more work on clock connections, but most of it is there. 

> 

> I know the CSM flow still dies on a couple of large blocks < I also 
>know that Dave is very busy . . ) . 

> 

> I'd like to try a toplevel DRC as soon as possible to see how long it 
>takes and to find algorithmicly generated drvs. 

> 

> Can someone (maybe someone else than Dave) have a look at the flow ? 
> 

> with some luck, we should be able to run an LVS shorts test by the end 
>of the week. 

> 

> Geert 


The problem with drc jobs dieing is not with the flow, but with dracula. 
There appears to be a bug in dracula that causes the SIZE module to bomb out. I ran a 
test on hestia with the latest version of dracula and it worked on a block that used to 
fail. However, when I had tacmo try it out, his whole environment was messed up and no 
dracula binaries were found. 

I can have some one else try a test tomorrow to help track down the environment problem. 
If it does work, then I can have a couple of machines upgraded with this new version. 

I'm leary about installing this new version of dracula just as we are trying to tapeout 
euterpe. There could be some subtle differences in the tool which will cause all kinds of 
problems when we least need them. 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 


Dave 
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From: vanthof (vant) 

Sent: Sunday, August 1 3, 1 995 11 :04 PM 

To: Kurt Wampler 

Cc: vanthof {Dave Van't Hot); hopper (Mark Hofmann); tor (Tim B. Robinson); torn (Tom Laidig) 

Subject: RE: fracture crash 


Kurt Wampler writes: 
> 

>Well ... I logged in with the intent of responding to the pages from 
>Hopper and Torn, but it appears that in the mean time (after reading the 
>4 0+ email messages that had stacked up since this morning) that Tom has 
>restarted fracture of layers 12Q-140. as long as no more getboms are 
>done in the mean time, those layers should complete successfully. 
>There are no post- fracture DRC errors at this time to be scrutinized. 
> 

>In a way, I think we have just proved to ourselves that we weren't 
>really ready yet to tape this chip out. The number of edits & checking 
>still taking place is rather alarming. What I *would* like to get out 
>of this fracture exercise is a good look at the lower layers on Monday, 
>paying particular attention to: 
> 

> 1) Interface between frame & die 

> 2) Layers with complex synthesis formulae (Vt, P/N, emitter implants) 
> 

>I don't feel very confident about shipping any of the layers we've 

>fractured so far. . . 

> 

>I'll stay logged in this afternoon if there are any dangling loose ends 
>that you need me to work on. Have we got the fatwire pad target 
>problem sufficiently fixed so that Tim can launch a new place & route? 

> 

>- Kurt 


Well, I do feel pretty confident about the fracture job and in fact would like to ship 
tapes on monday. Tom has put together a script which is comparing two directories of 
layouts. We can easily compare the snapshot version against the version being used for 
drc's. If these are the same, then I'd say we did a pretty good job of keeping things 
consistent. 

We knew ahead of time that there would be tons of edits going on. What we did not count on 
was the number of times that lower layers were edited/ but I think that's under control 
now. 

Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender 1 I mean, I know it, I'm not dumb... just 
not in this context." The Tick to Thrackazog 
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From: 
Sent: 
To: 
Cc: 


Subject: 


tbr 

Sunday, August 13, 1995 5:11 PM 
torn (Tom Laidig [tau]) 

hopper (Mark Hofmann); tau; vanthof (Dave Van't Hof); Kurt Wampler 
RE: fracture crash 


Tom Laidig [tau] wrote (on Sun Aug 13) : 

Kurt Wampler writes: 

Well ... I logged in with the intent of responding to the pages from Hopper 
and Tom, but it appears that in the mean time (after reading the 40+ email 
messages that had stacked up since this morning) that Tom has restarted 
fracture of layers 120-140. As long as no more getboms are done in the 
mean time, those layers should complete successfully. There are no 
post -fracture DRC errors at this time to be scrutinized. 

Yeah, things happen fast sometimes... thanks for checking the 
post-fracture DRC results. BTW, I moved the previous euterpe_lower.log 
to euterpe__lower. log.2, in case people want to look at it. 


In a way, I think we have just proved to ourselves that we weren't really 
ready yet to tape this chip out. The number of edits & checkins still 
taking place is rather alarming. 

Well, we're obviously not ready yet to tape out the upper layers, and I 
think we've proven that we weren't methodologically ready to tape out 
the lower layers while the upper layers are still in flux. I think 
we're more ready to do that kind of thing now. It seems to me that 
there were two main things wrong with our methodology: 


we didn't have an automated check in place to be alert to lower 
layer changes 

This has been fixed: a check is made every 4 hours, with error 
mail sent to me and dave (anybody else want to be on the ~to' 
list?) 

we should have started the fracture on a separate copy of the 
layouts 

I think this is something we should address before we embark on 
another gradual tapeout. Since it seems likely that most such 
tapeouts would happen simultaneously with the launching of the 
final DRC run (as happened this time), perhaps it makes sense 
for the DRC and fracture to share the frozen layout directory. 


I think so, and in fact I had been assuming that was the case this time. Obviously in the 
ideal case the snapshot would be just that and we'd not have this problem. 

Also, we need to prepare for a final fracture run where we verify that 
a lower- layer fracture now would produce the same tapes we sent 
yesterday (or some such combination of verb tenses) . I'd like to fire 
up such a comparison now for layers 010-110. 

Of course, personally, the idea of taping out lower layers while the 
uppers are still being furiously edited makes me want to take the 
metaphorical equivalent of a long hot shower. Sadly, the economics of 
time suggest that we'd better get used to doing business this way. I 
certainly can't justify delaying each tapeout by 2 or 3 weeks (equals 
$700k-$lM of fab burn or something?) for a little methodological purity 
and peace of mind. 
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Reckon $80K/day if you consider the whole operation. Of course if you assume one day we 
are shipping for revenue, lost opportunity could be much higher. It's certainly agreed at 
hich levels that there is risk in the current strategy and that we will pay to re -write 
masks if we have to. 

What I *would* like to get out of this 
fracture exercise is a good look at the lower layers on Monday/ paying 
particular attention to: 

1) Interface between frame & die 

2) Layers with complex synthesis formulae (Vt, p/N, emitter implants) 

I don't feel very confident about shipping any of the layers we've fractured 
so far. . . 

Well, I suspect we'll ship 'em anyway, and run some more post-hoc 
verifications. Hopefully, we'll be lucky and have to retract only a few 
tapes at most. 


I ' 11 stay logged in this afternoon if there are any dangling loose ends 
that you need me to work on. Have we got the fatwire pad target problem 
sufficiently fixed so that Tim can launch a new place & route? 

I think we hope this is the case, but I sure couldn't say... 

It will be a few more hours before it gets past the place where is crashed last time, but 
it' s OK so far. . . 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


torn (Tom Laidig [tail]) 

Sunday, August 13, 1995 4:43 PM 

Kurt Wampler 

tau; hopper (Mark Hofmann); tbr (Tim B. Robinson); vanthof (Dave Van't Hof) 
RE: fracture crash 


Kurt Wampler writes: 

Well ... I logged in with the intent of responding to the pages from 
Hopper and Tom, but it appears that in the mean time (after reading the 
4 0+ email messages that had stacked up since this morning) that Tom has 
restarted fracture of layers 12 0-140. As long as no more getboms are 
done in the mean time, those layers should complete successfully. 
There are no post- fracture DRC errors at this time to be scrutinized. 

Yeah, things happen fast sometimes... thanks for checking the post-fracture DRC results. 
BTW, I moved the previous euterpe_lower.log to euterpe_lower . log . 2 , in case people want to 
look at it. 


In a way, I think we have just proved to ourselves that we weren't 
really ready yet to tape this chip out. The number of edits & checkins 
still taking place is rather alarming. 

Well, we're obviously not ready yet to tape out the upper layers, and I think we've proven 
that we weren't methodologically ready to tape out the lower layers while the upper layers 
are still in flux. I think we're more ready to do that kind of thing now. It seems to me 
that there were two main things wrong with our methodology: 

we didn't have an automated check in place to be alert to lower 
1 aye r change s 

This has been fixed: a check is made every 4 hours, with error 
mail sent to me and dave (anybody else want to be on the "to 1 
list?) 

we should have started the fracture on a separate copy of the 


I think this is something we should address before we embark on 
another gradual tapeout. Since it seems likely that most such 
tapeouts would happen simultaneously with the launching of the 
final DRC run (as happened this time) , perhaps it makes sense 
for the DRC and fracture to share the frozen layout directory. 

Also, we need to prepare for a final fracture run where we verify that a lower- layer 
fracture now would produce the same tapes we sent yesterday (or some such combination of 
verb tenses) . I'd like to fire up such a comparison now for layers 010-110. 

Of course, personally, the idea of taping out lower layers while the uppers are still 
being furiously edited makes me want to take the metaphorical equivalent of a long hot 
shower. Sadly, the economics of time suggest that we'd better get used to doing business 
this way. I certainly can't justify delaying each tapeout by 2 or 3 weeks (equals 
§700k-$lM of fab burn or something?) for a little methodological purity and peace of mind. 

What I *would* like to get out of 
this fracture exercise is a good look at the lower layers on Monday, 
paying particular attention to: 

1) Interface between frame & die 

2) Layers with complex synthesis formulae (Vt, P/N, emitter implants) 

I don't feel very confident about shipping any of the layers we've 
fractured so far. . . 


layouts 
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well, I suspect we'll ship 'em anyway, and run some more post-hoc verifications. 
Hopefully, we'll be lucky and have to retract only a few tapes at most. 


I'll stay logged in this afternoon if there are any dangling loose ends 
that you need me to work on. Have we got the fatwire pad target 
problem sufficiently fixed so that Tim can launch a new place & route? 

I think we hope this is the case, but I sure couldn't say... 
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Sent: 

To: 

Cc: 


Subject: 


From: 


hopper (Mark Hofmann) 
Sunday, August 13, 1995 9:24 AM 
Kurt Wampler 

tbr (Tim B. Robinson); torn (Tom Laidig); vanthof (Dave Van't Hof) 
RE: fracture crash 


Kurt Wampler writes: 

Well ... I logged in with the intent of responding to the pages from Hopper 
and Tom, but it appears that in the mean time (after reading the 40+ email 
messages that had stacked up since this morning) that Tom has restarted 
fracture of layers 120-140. As long as no more getboms are done in the 
mean time, those layers should complete successfully. There are no 
post- fracture DRC errors at this time to be scrutinized. 

In a way, I think we have just proved to ourselves that we weren't really 
ready yet to tape this chip out. The number of edits & checkins still 
taking place is rather alarming. What I *would* like to get out of this 
fracture exercise is a good look at the lower layers on Monday, paying 
particular attention to: 

1) Interface between frame & die 

2) Layers with complex synthesis formulae {Vt, P/N, emitter implants) 

I don't feel very confident about shipping any of the layers we've fractured 
so far. . . 

Okay. I think we would like to start another, parallel, fracture run pointing to the 
"immlayout2" (sp?) area. Do you think that reasonable? 

I'll stay logged in this afternoon if there are any dangling loose ends 
that you need me to work on. Have we got the fatwire pad target problem 
sufficiently fixed so that Tim can launch a new place & route? 

I don't believe so, unless Geert has been able to address the problem. 


- Kurt 


-hopper 
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From: 
Sent: 
To: 

Subject: 


wampler (Kurt Wampler) 
Sunday, August 13, 1995 4:21 PM 
hopper; tbr; torn; vanthof 
RE: fracture crash 


Well.., I logged in with the intent of responding to the pages from Hopper and Torn, but it 
appears that in the mean time (after reading the 40+ email messages that had stacked up 
since this morning) that Tom has restarted fracture of layers 120-140. As long as no more 
getboms are done in the mean time, those layers should complete successfully. There are 
no post- fracture DRC errors at this time to be scrutinized. 

in a way, I think we have just proved to ourselves that we weren't really ready yet to 
tape this chip out. The number of edits & checkins still taking place is rather alarming. 
What I *would* like to get out of this fracture exercise is a good look at the lower 
layers on Monday, paying particular attention to: 

1) Interface between frame & die 

2) Layers with complex synthesis formulae (Vt, P/N, emitter implants) 

I don't feel very confident about shipping any of the layers we've fractured so far... 

I'll stay logged in this afternoon if there are any dangling loose ends that you need me 
to work on. Have we got the fatwire pad target problem sufficiently fixed so that Tim can 
launch a new place & route? 


- Kurt 


Exhibit C17 


Page 39 of 148 


Sent: 

To: 

Cc: 


Subject: 


From: 


hopper {Mark Hofmann) 
Sunday, August 13, 1995 7:44 AM 
Tom Laidig [tau] 

wampler (Kurt Wampler); vanthof (Dave Van't Hof); tau; tbr (Tim B. Robinson); lisar (Lisa 
Robinson); geert (Geert Rosseel) 
Re: fracture died 


Tom Laidig [tau] writes: 

(this is mostly a summary of previous mail messages) 

The fracture flow died this morning because it couldn T t find a cell in 
the hierarchy. This happened because we're fracturing from the 
snapshot, which has been updated periodically while the fracture was in 
progress, and at least one such update brought it to an inconsistent 
state . 

We seem to have layers 010-110 finished, so we want to restart the 
fracture flow on layers 120-140. I can see how to do this, except that 
I'd also like to change the .boo file (which seems to be auto -generated 
in some way) so it takes layouts strictly from the directory 
/n/ cyclops/ sl/dracjobs/immlayouts2 (which is a frozen directory of 
layouts as they existed when the current lower- layer DRC run started) . 
Can you set this up? 

Also, I'm a bit worried about other layers being corrupt. There have 
been a distressing number of cases where people did silicon- layer edits 
while fixing SDEC problems, and although Dave has caught these and 
backed them out, I worry that they may have been in the snapshot for a 
time before we got the mechanisms in place to detect them in a timely 
fashion. Therefore, I'd like to start up a run to generate 010-110 from 
the /n/ cyclops/ si /dracj obs/immlayouts2 directory, and verify that the 
results are the same as what we have fractured already. I think this 
work can proceed in parallel with sending out the tapes. 


This sounds like a good way to proceed. Maybe in parallel with Kurt fixing up the .boo 
file you could do a restart on 12 0-140 pointing to the snapshot, just to finish off (and 
blunder- sweep) the fracture run? 


Tom, 


- thanks , 
hopper 
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Sent: 

To: 

Cc: 


Subject: 


From: 


torn {Tom Laidig [tau]) 

Sunday, August 13, 1995 2:38 PM 

wampler (Kurt Wampler) 

hopper (Mark Hofmann); vanthof (Dave Van't Hof); tau; tbr (Tim B. Robinson); lisar (Lisa 
Robinson); geert (Geert Rosseel) 
fracture died 


(this is mostly a summary of previous mail messages) 

The fracture flow died this morning because it couldn't find a cell in the hierarchy. 
This happened because we're fracturing from the snapshot, which has been updated 
periodically while the fracture was in progress, and at least one such update brought it 
to an inconsistent state. 

We seem to have layers 010-110 finished, so we want to restart the fracture flow on layers 
120-140. I can see how to do this, except that I'd also like to change the .boo file 
(which seems to be auto -generated in some way) so it takes layouts strictly from the 
directory 

/n/cyclops/sl/dracjobs/immlayouts2 (which is a frozen directory of layouts as they existed 
when the current lower- layer DRC run started) . 
Can you set this up? 

Also, I'm a bit worried about other layers being corrupt. There have been a distressing 
number of cases where people did silicon- layer edits while fixing SDEC problems, and 
although Dave has caught these and backed them out, I worry that they may have been in the 
snapshot for a time before we got the mechanisms in place to detect them in a timely 
fashion. Therefore, I'd like to start up a run to generate 010-110 from the 
/n/ cyclops/ sl/dracjobs/immlayouts2 directory, and verify that the results are the same as 
what we have fractured already. I think this work can proceed in parallel with sending 
out the tapes. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Saturday, August 12, 1995 10:33 AM 

vant 

hopper@microunity.com; torn (Tom Laidig); tbr (Tim B. Robinson); geert (Geert Rosseel); 

vanthof (Dave Van't Hot) 

Re: output of euterpe/.checkoutrc (fwd) 


vant writes: 

Mark Hofmann writes: 

>l _think_ so, but I'm not sure, it sounds like these are the upper layers 
>of the pads so they shouldn't affect the lower tape out layers. And I assume 
>they ' ve been LVS ' d and DRC ' d . . . 

At this point, I think it is a bad assumption to think they are 
drc/lvs clean. 

Lot's of careless mistakes are being made with no verification done before 
checkins occur, because of this, I believe the next fullchip lvs will 
be a disaster. . . 


Arg. I fear you may be right. I think not a lot of the edit cells have undergone the full 
DRC. I think that's how many of them ended up on Solo's list still dirty. 


Dave 


-hopper 
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From: vanthof (vant) 

Sent: Saturday, August 12, 1995 4:05 PM 

To: Mark Hofmann 

Cc: torn (Tom Laidig); tbr (Tim B. Robinson); geert (Geert Rosseel); vanthof (Dave Van 1 t Hof) 

Subject: Re: output of euterpe/.checkoutrc (fwd) 


Mark Hofmann writes: 

>I _think_ so, but I'm not sure. It sounds like these are the upper 
>layers of the pads so they shouldn't affect the lower tape out layers. 
>And I assume they've been LVS 1 d and DRC'd... 
> 

> -hopper 


At this point, I think it is a bad assumption to think they are drc/lvs clean. 

Lot's of careless mistakes are being made with no verification done before checkins occur. 

because of this, I believe the next fullchip lvs will be a disaster... 

Dave 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context." The Tick to Thrackazog 
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Subject: 


Sent: 
To: 

Cc: 


From: 


lisar (Lisa Robinson) 

Saturday, August 12, 1995 2:30 PM 

Charlie Root 

brian; deepak; jeffm; tbr; veena 

Derek has a question about verilog wires.... 


Charlie Root wrote (on Sat Aug 12) : 


I am having trouble getting my C model to actually wiggle wires. To 
test an idea that Brian Smith gave me, I created two things 
(variables?) . 


And replaced that use of PciDEVSEL with wiredevsel and regdevsel . 
When I use undertow, I can verify that the regdevsel value can be 
changed by my model but the wiredevsel one does not, 

I have a feeling the problem is related to a verilog type problem in 
that I am not expressing my ability to drive the signals (perhaps 
wires default to be inputs instead of inouts?) . 

I was wonding if any of you were logged in today and might be able to 
suggest something. 

The verilog code I am using is in 


I don't think that I can be much here but are you sure that you are the only one driving 
the wires? If you are driving the wires with someething that doesn't "force" them they 
could be getting clobbered by something else, even an X or a Z (if they are floating for 
example) . You cannot guarantee the order of evaluation in the same simtick. 


wire 
reg 


wiredevsel; 
regdevsel ; 


/u/doi/chip/euterpe/verilog/bsrc/hc . test/pcitest . v 


Thanks , 
doi 


Lisa R. 
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Subject: 


From: 
Sent: 
To: 
Cc: 


tbr 

Saturday, August 12, 1995 2:22 PM 
hopper (Mark Hofmann) 

geert (Geert Rosseel); tau; Tom Laidig [tau]; vanthof (Dave Van't Hof) 
Re: output of euterpe/.checkoutrc (fwd) 


Mark Hofmann wrote (on Sat Aug 12) : 

Tom Laidig [tau] writes: 

I think this is the result of Tim doing a top-level release of euterpe. 
It died trying to abstract the baseplate, because it couldn't find the 
layout files: 

padcrack_uplay . ly 
pads eal_up lay . ly 
padm , ly 

which are in proteus/compass/layouts , but haven't been released. I'm 
guessing vant • s blanket release last night missed them because his cell 
list is newly out of date -- these cells were first created yesterday. 

Should I release them now? 


I _think_ so, but I'm not sure. It sounds like these are the upper layers 
of the pads so they shouldn't affect the lower tape out layers. And I assume 
they ' ve been LVS ' d and DRC ' d . . . 

There is another problem wher 3 handle with care nets not routing. 

Geert is looking at it but has not found anything wrong. Could this be related? 


Esnip) 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 
Saturday, August 12, 1995 7:14 AM 
Tom Laidig [tau] 

tbr (Tim B. Robinson); vanthof (Dave Van't Hof); tau; geert (Geert Rosseel) 
Re: output of euterpe/.checkoutrc (fwd) 


Tom Laidig [tau] writes: 

I think this is the result of Tim doing a top-level release of euterpe. 
It died trying to abstract the baseplate, because it couldn't find the 
layout files : 

padcrack_uplay . ly 
padseal_uplay . ly 
padm . ly 

which are in proteus/compass/layouts, but haven't been released. I'm 
guessing vant • s blanket release last night missed them because his cell 
list is newly out of date -- these cells were first created yesterday. 

Should I release them now? 


I _think_ so, but I r m not sure. It sounds like these are the upper layers of the pads so 
they shouldn't affect the lower tape out layers. And I assume they've been LVS ' d and 
DRC'd. . . 


[snip] 


-hopper 
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From: torn (Tom Laidig [tau]) 

Sent: Saturday, August 1 2, 1 995 1 :43 PM 

To: tor (Tim B. Robinson); vanthof (Dave Van't Hof) 

Cc: tau; hopper (Mark Hofmann); geert (Geert Rosseel) 

Subject: output of euterpe/.checkoutrc (fwd) 


I think this is the result of Tim doing a top-level release of euterpe . 
It died trying to abstract the baseplate, because it couldn't find the 
layout files: 

padcrack_uplay . ly 
padseal_uplay . ly 
padm . ly 

which are in proteus/compass/layouts , but haven't been released. I'm 
guessing vant's blanket release last night missed them because his cell 
list is newly out of date -- these cells were first created yesterday. 

Should I release them now? 

Potatoe Chip writes: 
From chip Fri Aug 11 23:19:34 1995 
Date: Fri, 11 Aug 1995 23:19:22 -0700 
From: chip (Potatoe Chip) 

Message- Id: <19950812 0619 . XAA23071@staypuf t .microunity . com> 
To : doi , torn 

Subject: output of euterpe/.checkoutrc 

Fri Aug 11 22:56:49 PDT 1995 (chip Fri, 11 Aug 1995 22:56:41 -0700) euterpe 
[Release BOM (V5.0) in euterpe (Fri Aug 11 22:56:49 PDT 1995)] 


Dir euterpe BOM 5.0 

1.2 .checkoutrc 

1.13 Makefile 

1.4 Makefile. defs 
1.1 Makefile, rules 

Dir euterpe/baseplate BOM 26.0 

1.9 . checkoutrc 
1.52 Makefile 

1 . 1 clean_reguest 

1 . 5 clockparms .m4 
3 . 22 custom. pif 

1.8 ecl_cutout . sgen.m4 

3 . 2 f loorplan. pif 
1.45 f loorplan. sgen.m4 
15 . 1 membrane . 1st 

5.10 mos_cutout . sgen. m4 
1.29 padlist.lst 

1.5 padring. sgen.m4 

1.3 spacetrans . sgen . m4 

Dir euterpe/clockbias BOM 7.0 

1.8 . checkoutrc 
1.28 Makefile 

5 . 1 clockbias . domains 

Dir euterpe/compass BOM 7.0 

1.9 vlsi. boo-all 

1.8 vlsi .boo-dcell 

1 . 9 vlsi .boo- tapeout 
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Dir euterpe/ compass /layouts bom 21.0 

1.1 . checkoutrc 

1.2 Makefile 

5 . 5 euterpe-hwc . ly 

1 . 4 euterpe . db 

2.3 euterpelpadtl . ly 
2 . 2 euterpelpadtr . ly 
10.9 f0007.1y 

19.3 f0007_fill_ctpg.ly 

19,3 f0007_fill_ml.ly 

19. 3 f 0007_f ill_tn2 . ly 

19.3 f 0007_f ill_m3 . ly 

19.3 f0007_fill_m4 .ly 

19 . 3 f 0007_f ill_vl2 . ly 

19.3 f 0007_£ill_v23 . ly 

19 . 3 f 0007_f ill_v34 . ly 

19 . 3 f 0007_£ ill_v45 . ly 

10.1 fOOOS.ly 

2 . 5 lid_euterpe_l . ly 

8.1 1 id_euterpep_l . ly 
n.i locked-cells 

6.2 pllwl.ly 
6 . 1 pllw2 . ly 

12 . 2 probe_template . ly 
8 . 2 steuterpelpadtl . ly 
8 . 2 st euterpelpadtr . ly 
4 . 11 vdda_partition. ly 

1.4 vlsi.atr 

2 .37 vlsi . cko 

11 . 1 vlsi . idx 
2 .40 vlsi . log 

Dir euterpe/dcell BOM 18.0 

1.5 . checkoutrc 
1.42 Makefile 

10.4 auindx. dcell 
1.5 cc.dcell 

3 . 6 cdio . dcell 

1 . 26 cerberus .dcell 

1.9 cj .dcell 

14 . 2 ck_£ gen . dcell 

I. 2 clean-request 

13.2 cp. dcell 

II. 4 ctio. dcell 
1.2 dcelldef s .m4 
1.5 dr. dcell 

1.2 drio. dcell 
8.8 es. dcell 
2.20 gt. dcell 
1.5 he. dcell 
14 .1 hz. dcell 
1.8 ife. dcell 

10 . 3 iorate . dcell 

1.7 iq. dcell 
2.13 It. dcell 
9.4 mc. dcell 

10.6 mst. dcell 

1.8 nb. dcell 

13 .4 rg. dcell 

1 . 15 rgxmit .dcell 

11.7 sr. dcell 
1.19 uu. dcell 
1 . 4 xlu. dcell 

Dir euterpe/doc BOM 22 . 0 

4 . 11 Makefile 

4.3 9 cerberus. mif 
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12.5 changes. mi f 
9.1 cjprint.doc 

19.6 clock. mif 

1 . 1 computeEq . c 

8 . 1 csprint . doc 

19.6 endian.mif 

4.15 euterpe-microarch.book 

4.14 euterpe-microarchTOC.mif 

1.25 euterpe.doc 

4 . 24 events , mif 

16.8 front. mif 

4 . 22 intro.mif 

4.36 memory. mif 

4 . 24 opcodes .mif 

4 . 24 pipeline . mif 

7 . 3 print . doc 

4.22 reset. mif 

1.1 test,eq 

19.2 testerinit.html 

18.19 verify.html 

4 . 21 xlu.mif 

Dir euterpe/doc/debug BOM 3.0 

1 . 1 DebugExaraple_bad . html 

1 , 1 DebugExample_head . html 

1 . l DebugExample_llev, html 

1 . 1 DebugExample_llnav . html 

1 , 1 DebugExample__nav . html 

1 . 1 DebugExample_xcor . html 
1 . 4 EuterpeDebug . html 

1 . 2 EuterpeDebug_not_obv . html 
1.2 EuterpeDebug_obv.html 

1 . 1 EuterpeDebug_pipe . html 

1 . 4 Logf iles .html 

1 . 5 Simula tor_conf iguration.mif 

1 . 2 likedriverlog_f Ids . html 
1 . 2 likedriver log_nav . html 
l.l likedriverlog_x.html 

Dir euterpe/gards BOM 4.0 

1.8 . checkoutrc 

1.50 Makefile 

1.1 sclean- request 

Dir euterpe/ged BOM 3 . 0 

1.1 . checkoutrc 
1.8 Makefile 

1 . 8 README 

Dir euterpe/ged/rf BOM 3 . 0 

Dir euterpe/ged/rf /rfereg BOM 3.0 

1.2 spice. l.l 
1 . 2 spice .1.2 
1.2 spice. 1.3 
1,2 spice. 1.4 
1 . 2 spice .1.5 
1.2 spice_cn. 1 . 1 
1.2 spice_cn.l.2 
1 . 2 spice_cn. 1 . 3 

1 . 2 spice_cn .1.4 
1 . 2 spice_cn. 1 . 5 

Dir euterpe/ged/rf /rf ereg/hspice BOM 3.0 

1.3 Makefile 

1 . 3 rfereg. hdr 
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Dir euterpe/ged/rf /rfureg BOM 3.0 

1.2 spice. 1.1 

1.2 spice. 1.2 

1 . 2 spice .1.3 

1.3 spice. 1.4 
1.2 spice. 1.5 

1 . 2 spice_cn. 1 . 1 

1 . 2 spice_cn. 1 . 2 

1.2 spice_cn.l.3 

1.3 spice_cn.l.4 
1.2 spice_cn.l.5 

Dir euterpe/ged/rf /rf ureg/hspice BOM 3.0 

1 . 2 r fur eg. hdr 

Dir euterpe/ged/rf /sbreg BOM 3.0 

1.2 spice. 1.1 

1.2 spice. 1.2 

1.2 spice. 1.3 

1.3 spice. 1.4 
1 . 2 spice .1.5 
1.2 spice_cn.l.l 
1 . 2 spice_cn. 1 . 2 

1 . 2 spice_cn. 1 , 3 

1.3 spice_cn.l.4 
1.2 spice_cn. 1 .5 

Dir euterpe/ged/rf /sbreg/hspice BOM 3 . 0 

1 . 2 sbreg . hdr 

Dir euterpe/misc BOM 2.0 

1 . 1 gards . ctrl 

1 . 1 gards . spn 

1 . 9 gards. vrf 

1.1 global.net 

Dir euterpe/tab BOM 6.0 

1 . 1 .checkoutrc 

1.4 Makefile 
4 . 1 README 

Dir euterpe/verify BOM 5.0 

3 . 12 Makefile 

4 . 2 Makefile . cmp 
1.38 Makefile. defs 
1 , 66 Makefile . rules 

3 . 13 Makerules . local 
3 . 10 status 

Dir euterpe/verify/conf ig BOM 5.0 

1 . 1 cde . hdr 

1.1 cdo.hdr 

1 . 1 cerb . hdr 

4.1 cerbrom.hdr 

1.1 cie.hdr 

1,1 c io . hdr 

3 . 1 conf ig.hdr 

1.1 ctd.hdr 

1.1 cti.hdr 

1 . 2 dram . hdr 

1 . 2 i_euterpe_wrap . parm 
1 . 1 rom . hdr 

Dir euterpe/verify/ include BOM 35.0 

1.3 . checkoutrc 
1.15 Makefile 
10.19 cerberus. h 
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9.3 clean- request 
1.35 end.S 

14.5 hold.S 

4.23 physaddr . h 

18.2 start. S 

Dir euterpe/verif y/nasty BOM 18 . 0 

1.1 . checkoutrc 

2.1 . cvsignore 

1.11 Makefile 

1 . 2 cachenasty . S 
1 . 2 cachenasty2 . S 
1 . 2 cachenasty3 . S 
1.2 cachenasty4 . S 

1.5 cachenasty5 . S 

11.1 cachenasty5_var_al_l . exe 

ll.l cachenasty5_var_bl_l . exe 

11.1 cachenasty5_var_cl_l . exe 

11.1 cachenasty5_var_dl_l . exe 

11.1 cachenasty5_var_el_l . exe 

1 . 2 cachesynchnasty . S 

1 . 6 cachesynchnasty2 . S 

11.1 cachesynchnasty2_var_al_l . exe 

11 . 1 cachesynchnasty2_var_bl_l . exe 

11 . 1 cachesynchnasty2_jvar_cl_i .exe 

11.1 cachesynchnasty2_var_dl_l . exe 

11 . 1 cachesynchnasty2_var_el_l . exe 

1 . 2 clean- request 

3.4 exintbash.S 

1.12 hermnasty.S 

Dir euterpe/verify/perf BOM 3.0 

1.1 . checkoutrc 

1.3 Makefile 

1 . 3 cerb_perf . S 

1.1 clean-request 

1.3 dcache_jperf .S 

1 . 1 dcachemiss_perf . S 

1 . 3 drarnjperf . S 

1 . 3 hermes_perf . S 

1.3 rom_jperf ,S 

Dir euterpe/ verify/random BOM 5.0 

2.1 . checkoutrc 

1.2 0 Makefile 

2.1 clean- request 
3 . 1 exclude 

3.2 exclude_all 

3 . 1 exclude_all_but_e 

3 . 1 exclude_all_but_extract 

2.1 exclude_mul_and_extract 

3.2 exclude_nothing 

3 .2 regdepend_rl001 .S 

3 . 1 regdepend_rll22 . S 

3 . 2 regdepend__rl578 . S 

3 . 1 regdepend_rl639 . S 

3 . 2 regdepend_rl742 . S 

3.1 regdepend_rl7803 . S 

2 . 2 regdepend_rl794 . S 
3.1 regdepend_rl7972 .S 
3.1 r egdepend_r 18300 .S 
3.1 regdepend_rl84 69.S 

3 . 1 regdepend_r 184 7 . S 

3.2 regdepend_rl906 .S 

3 . 1 regdepend_rl9204 . S 

3 . 1 regdepend_rl9368 . S 

2 . 2 regdepend_r 19 3 7 . S 
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3 . 1 regdepend_rl9537 . S 

3 . 1 regdepend_rl970l . s 

3 . 1 regdepend_r!9865 .S 

3 . 1 regdepend_r2057 . S 

2 . 2 regdepend_r2 0 1 9 . S 
3 . 1 regdepend_r2 14 3 5 . S 
3.1 regdepend__r21599.S 
3 . 1 regdepend_r21768 . S 
3 . 1 regdepend_r2l932 .S 

3 . 1 regdepend_r22096 .S 

2 . 2 regdepend_r2226 . S 

3 . 1 regdependr2 2 7 9 . S 

2 . 2 regdepend_r2368 . S 
3 . 1 regdepend_r2476 . S 
3 . l regdepend_r2493 . S 
3 . 1 regdepend_r25547 . S 
3 . 1 regdepend_r25728 . S 
3 . 1 regdepend_r2688 . S 
3 „ 1 r egdepend_r2 S 9 5 . S 
3 . 1 regdepend_r2 8 95 . S 
3 . 1 regdepend_r3 064 . S 
3 . 1 regdepend_r3 094 . S 
3 . 1 r egdepend_r3 3 6 2 . S 

3 . 1 r egdepend_r3 5 6 1 . S 

2 . 2 regdepend_r393 . S 
3 . 1 regdepend_r3 95 7 . S 
3 . l regdepend_r4i57 . S 
3 . 1 regdepend_r4 3 5 6 . S 
3 . 1 regdepend_r 4 5 5 2 . S 
3 . 1 r egdepend_r 4 7 5 2 . S 
3 . 1 regdepend_r4951 . S 

3 . 1 regdepend_r 5 1 52 . S 

2 . 2 regdepend_r52 1 . S 
3 . 1 regdepend_r5352 . S 

3 . 1 regdepend_r5557 . S 

2 . 2 regdepend_r5564 . S 
2 . 2 regdepend_r57l2 . S 

3.1 regdepend_r5757 . S 

2 . 2 regdepend_r5854 . S 

3 . 1 regdepend_r 5 9 5 7 . S 
2 . 2 regdepend_r5996 . S 

2.2 regdepend_r6i43 .S 
3.1 regdepend_r6152 .S 
2 . 2 regdepend__r6308 . S 

3 . 1 regdepend_r6352 . S 

2 . 2 regdepend_r6450 . S 
2 . 2 regdepend_r656 . S 
2 . 2 r egdepend_r 6 5 9 7 . S 
2 . 2 r egdepend_r 6 7 3 9 . S 
2 . 2 r egdepend_r 6 8 8 1 . S 
2 . 2 r egdepend_r 7 2 1 0 . S 
2 . 2 regdepend_r733 8 . S 
2.2 regdepend_r74 95.S 

3 . 1 regdepend_r754 . S 

2 . 2 regdepend_r7623 . S 
2.2 regdepend_r7751.S 
2 . 2 r egdepend_r 7 8 6 . S 
2 . 2 regdepend_r915 . S 
2 . 12 status 

3.1 stgen_rl0803 .S 

3 . 1 stgen_rl0987 . S 

3.1 stgen_rll3 62.S 

3.1 atgen_rl3 311.S 

3.1 stgen_rl6899.S 

3.1 stgen_rl7070.S 

3.1 stgen_rl7235.S 

3.1 stgen_rl7405.S 
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1 3.1 stgen_r22478.S 

3.1 stgen„r29924.S 

3.1 stgen_r8191 . S 

3 . 1 stgen_teraplate 

2 . 12 template 

Dir euterpe /verify/ standalone BOM 5 . 0 

1 . 9 template 

Dir euterpe/ verify/ st andalone/au BOM 2,0 

l.l . checkoutrc 

1.3 Makefile 

1 . 1 auadd.pl 

1 . 1 auaddi .pi 

1 .1 auand.pl 

1 . 1 auandi . pi 

1 . 1 auandn . pi 

1 . 5 aubranch . pi 

1 . 3 aubrf short . pi 

1 . 1 aubrshort .pi 

1.1 aucopyi.pl 

1 . 8 aulib.cpp 

1.1 aunand.pl 

1 , 1 aunandi . pi 

1.1 aunor.pl 

1.1 aunori.pl 

1 . 1 auor . pi 

1.1 auori.pl 

1.1 auorn.pl 

1 . 2 aurandom . pi 

1.2 aushli.pl 

1.3 aushort.pl 
1.1 aushri.pl 
1 . 1 aushrui . pi 
1.1 ausub-pl 

1 . 1 ausubi .pi 

1 . 3 autest .pi 

1 . 1 auxnor . pi 

1 . 1 auxor . pi 

1 . 1 auxori .pi 

Dir euterpe/verify/standalone/ce BOM 2 . 0 

1.1 . checkoutrc 

1.3 Makefile 

1.2 ce.srl 

1 . 1 ce_debug . srl 

1 . 1 ce_def aults . S 

1 . 1 ce_def aults . loop 

1 . 2 ce_def aults . pi 
1.1 ce_defer.pl 

1 . 1 ce_norom . S 

1 . 1 ce_norom . pi 

1 . 1 ce_rom. S 

1.1 ce_rom.pl 

1 . 1 clean- request 

1.1 testlib.pl 

Dir euterpe/verify/standalone/dp BOM 19.0 

1.4 . checkoutrc 
1.49 Makefile 

1 . 1 chkmatch 

1.10 clean-request 

7 . 1 dpeSmuxspc . test 

1.2 dpeadd.test 
1.2 dpeaddi.test 
2 . 1 dpeaddio . test 

2 . 1 dpeaddiospc . test 
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2 . 1 dpeaddispc . test 

2 . 1 dpeaddiuo . test 

2 . 1 dpeaddiuospc . test 

2 . l dpeaddo . test 

2 . 1 dpeaddospc . test 

2 . 1 dpeaddspc . test 

2 . 1 dpeadduo . test 

2 . 1 dpeadduospc .test 

1.2 dpeand.test 
1 . 2 dpeandi . test 

2 . 1 dpeandispc . test 

1 . 2 dpeandn . test 

1 . 2 dpeandnspc . test 

1 . 2 dpeandspc . test 

1 . 2 dpeasum . test 

l . 2 dpebande . test 

2 . 1 dpebande spc .test 

1 . 2 dpebandne . test 

2 . 1 dpebandnespc .test 

1.2 dpebe.test 

2 . 1 dpebespc . test 
1 . 3 dpebge . test 

12 . 1 dpebgespc . test 

1 . 3 dpebl . test 

12.1 dpeblspc . test 

1 . 2 dpebne , test 

2 . 1 dpebnespc . test 

1 . 3 dpebuge . test 

12.1 dpebuge spc . test 

1.3 dpebul.test 

12.1 dpebul spc . test 

7 . 1 dpe copy swapi spc . test 

7 . 2 dpedepispc . test 

17.2 dpedepixspc . test 
2 . 1 dpeeasumspc . test 
1.2 dpelgcshort . test 

2.1 dpelms.test 

12.1 dpelrasspc. test 

7.2 dpemdepispc. test 

17.2 dpemdepixspc . test 
2 . 1 dpemshr .test 

2 . 1 dpemshri . test 

4.2 dpemshri spc . test 

4 . 2 dpemshrspc . test 

1 . 2 dpemux . test 

2.1 dpemuxspc . test 
1 . 2 dpenand . test 

1 . 2 dpenandi . test 

2 . 1 dpenandispc . test 

1 . 2 dpenandspc .test 
1.2 dpenor.test 

1 . 2 dpenori . test 

2.1 dpenori spc . test 

1 . 2 dpenorspc . test 
1.2 dpeor.test 

1.2 dpeori.test 

2.1 dpeorispc. test 

1.2 dpeorn.test 

1 . 2 dpeomspc . test 

1 . 2 dpeorspc . test 

2.1 dperotl . test 

4.1 dperotlspc . test 

2 . 1 dperotr . test 

2 . 1 dperotri . test 

4.1 dperotrispc. test 

4 . 1 dperotrspc . test 

7.1 dpeselect8spc . test 
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1 1 . 2 dpesete . test 

1 1 . 2 dpesetespc . test 

i 1 . 2 dpesetge . test 

1.2 dpesetgespc . test 

1 . 2 dpesetie . test 

2 . 1 dpesetiespc . test 

1 . 2 dpesetige . test 

2 . 1 dpesetigespc . test 

1 . 2 dpesetil . test 

2 . 1 dpesetilspc . test 

1 . 2 dpesetine . test 

2 . 1 dpesetinespc . test 

1 . 2 dpesetiuge . test 

2 . 1 dpesetiugespc . test 

1 . 2 dpesetiul . test 

2.1 dpesetiulspc . test 

1 . 2 dpesetl . test 
1.2 dpesetlspc . test 
1,2 dpesetne.test 

1 . 2 dpesetnespc . test 

1.3 dpeset short . test 
1 . 2 dpesetuge . test 

l . 2 dpesetugespc . test 

1 . 2 dpesetul . test 

1 . 2 dpesetulspc . test 

7.1 dpesf li4mxspc . test 
17.1 dpesf lxspc . test 

1.3 dpeshf t short . test 

1 . 2 dpeshl . test 
1.2 dpeshli.test 
2,1 dpeshlio. test 

2.1 dpeshl iospc . test 

2.2 dpeshlispc.test 
2 . 1 dpeshliuo . test 
2.1 dpeshl iuospc . test 

2 . 1 dpeshlo . test 

2 . 2 dpeshlospc , test 
2 .2 dpeshlspc . test 
2 . 1 dpeshluo . test 

2 . 1 dpeshluospc . test 

1.2 dpeshr.test 
1 . 2 dpeshri . test 

2 . 2 dpeshrispc . test 

2 . 2 dpeshrepc . test 

7 . 1 dpeshuf f leispc . test 

1.2 dpesub.test 
1.2 dpesube . test 

2 . 1 dpesubespc . test 

1 . 2 dpesubge . test 

2 . 1 dpesubgespc . test 

1.2 dpesubi . test 
1.2 dpesubie . test 

2 . 1 dpesubiespc . test 

1 . 2 dpesubige . test 

2.1 dpesubigespc . test 

1.2 dpesubil . test 

2 . 1 dpesubilspc . test 

1 . 2 dpesubine . test 

2 . 1 dpesubinespc . test 

2.1 dpesubio. test 

2 . 1 dpesubiospc . test 

2.1 dpesubi spc . test 

1 . 2 dpesubiuge . test 

2 . 1 dpesubiugespc . test 

1 . 2 dpesubiul . test 
2.1 dpesubiul spc . test 
2 . 1 dpesubiuo . test 
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2 . 1 dpesubiuospc . test 

1.2 dpesubl . test 

2 . 1 dpesublspc . test 

1.2 dpesubne. test 

2 . 1 dpesubnespc . test 

2 . 1 dpesubo . test 

2.1 dpesubospc . test 

1 . 4 dpesubshort . test 

2 . 1 dpesubspc . test 

1.2 dpesubuge.test 

2 . 1 dpesubugespc . test 

1.2 dpesubul . test 

2 . 1 dpesubulspc . test 

2 . 1 dpesubuo . test 

2 . 1 dpesubuospc . test 

7 . 1 dpetrSmuxspc . test 

7 . 2 dpeudepispc . test 
17 . 2 dpeudepixspc . test 

2.1 dpeulms.test 

12.1 dpeulmsspc . test 

1.2 dpeushr . test 
1 . 2 dpeushri . test 

2 . 2 dpeushrispc . test 

2 . 2 dpeushrspc . test 

7 . 2 dpeuwthispc . test 

17 . 2 dpeuwthixspc . test 
7 . 2 dpewthispc .test 
17.2 dpewthixspc . test 
12 . 1 dpexlushort . test 
1.2 dpexnor.test 

1 . 2 dpexnorspc . test 

1 . 2 dpexor . test 

1 . 2 dpexori . test 

2 . 1 dpexorispc , test 

1 . 2 dpexorspc . test 

7 . 1 dpg8muxspc . test 

1.3 dpgadd.test 

2 . 1 dpgaddspcl6 . test 

2 . 1 dpgaddspc32 .test 

2 . 1 dpgaddspc4 . test 

2 . 1 dpgaddspc64 . test 

2 . 1 dpgaddspc8 . test 

1.2 dpgand.test 
1 . 2 dpgandn .test 

2 . 1 dpgandnspc . test 

2 . 1 dpgandspc . test 

4 . 1 dpgcmpshortspc . test 

2 . 2 dpgcorapress . test 
2 . 2 dpgcorapressi . test 

2 . 1 dpgcompressispcl . test 

2 . 1 dpgcompressispcl6 . test 

2.1 dpgcompressispc2 . test 

2 . 1 dpgcompressispc32 . test 

2 . 1 dpgcompressispc4 . test 

2 . 1 dpgcompressispc64 . test 

2 . 1 dpgcompressispc8 . test 

2 . 1 dpgcompressspcl . test 

2 . 1 dpgcompressspclS . test 

2 . 1 dpgcompressspc2 . test 

2 . 1 dpgcorapressspc32 . test 

2 . 1 dpgcompressspc4 . test 

2.1 dpgcompressspc64 . test 

2 . 1 dpgcorapress spc 8 . test 

7 . 1 dpgcopyswapcpispc . test 

7 . 1 dpgcopyswapispc . test 

7 . 1 dpgcopyswapswispc . test 

7 . 2 dpgdepispc . test 
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17 . 2 dpgdepixspc . test 

2 . 2 dpgexpand . test 

2 . 2 dpgexpandi . test 

2 . 1 dpgexpandi spcl . test 

2 . 1 dpgexpandi spc 16 .test 

2 . 1 dpgexpandi spc 2 . test 

2 . 1 dpgexpandi spc3 2 . test 

2 . 1 dpgexpandi spc4 . test 

2.1 dpgexpandi spc 64 . test 

2 . 1 dpgexpandispc8 . test 

2 . 1 dpgexpandspcl . test 

2 . 2 dpgexpandspcl 6 . test 
2 . 1 dpgexpandspc2 .test 
2 . 1 dpgexpandspc32 . test 
2 . 1 dpgexpandspc4 . test 
2 . 1 dpgexpandspc64 . test 
2.1 dpgexpandspc 8 . test 

4 . 1 dpgexpshortspc . test 
12 . 1 dpgextractispc . test 
12.1 dpgextractispcl28 . test 

12 . 1 dpgextractispc64 . test 

12.2 dpgextractspcl28 . test 
17.1 dpggfmul8 spc . test 

12 . 1 dpgkarzexpe . test 

12 . 1 dpgkarzext2 . test 

12 . 1 dpgkarzext3 . test 

7 . 3 dpgmdepispc . test 

17.2 dpgmdepixspc . test 
2 . 2 dpgmshr . test 

2.2 dpgmshri.test 

4 . 1 dpgmshrispcl28 . test 

4 . 1 dpgmshrispcl6 . test 

4 . 1 dpgmshrispc2 . test 

4.1 dpgmshrispc32 . test 

4 . 1 dpgmshrispc4 . test 

4 . 1 dpgmshr ispc64 . test 

4 . 1 dpgmshrispc8 . test 

4.1 dpgmshrspcl28 . test 

4.1 dpgmshrspcl6 . test 

4 . 1 dpgmshrspc2 . test 

4 . 1 dpgtnshrspc32 .test 

4 . 1 dpgmshrspc4 . test 

4 . 1 dpgmshrspc64 . test 

4 . 1 dpgmshrspc8 . test 

1 . 4 dpgmul . test 

1 . 2 dpgmuladdie . test 
1 . 1 dpgmuladd3 2 . test 
1 . 1 dpgmuladd4 .test 
1 . 2 dpgmuladd64 . test 
1 . 1 dpgmuladdS . test 

1 . 1 dpgmuladspclS . test 

1 . 1 dpgmuladspc32 . test 

1 . 1 dpgmuladspc4 . test 

1 . 1 dpgmuladspc64 . test 

1.1 dpgmuladspc8 . test 

2 . 2 dpgmulshort . test 
1 . 2 dpgmulspcl6 . test 
1.2 dpgmulspc32 . test 
1.2 dpgmul spc4 . test 
1 . 2 dpgmulspc64 . test 
1 . 2 dpgmulspc8 . test 
1.2 dpgmux.test 

2 . 1 dpgmuxspc . test 

1 . 2 dpgnand. test 

2 . 1 dpgnandspc . test 

1.2 dpgnor.test 

2 . 1 dpgnorspc .test 
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1.2 dpgor.test 

1 . 2 dpgorn. test 

2 . 1 dpgornspc . test 
2 . 1 dpgorspc . test 

2 . 2 dpgrotl . test 

4.1 dpgrotlspcl28 . test 

4 . 1 dpgrotlspcie . test 

4 . 1 dpgrotlspc2 .test 

4.1 dpgrotlspc32 . test 

4.1 dpgrotlspc4 . test 

4 . 1 dpgrotlspc64 . test 

4 . 1 dpgrotlspc8 . test 

2.2 dpgrotr.test 

2 . 2 dpgrotri . test 

4.1 dpgrotrispcl28 . test 

4.1 dpgrotri spcl6 . test 

4 . 1 dpgrotrispc2 . test 

4.1 dpgrotrispc32 . test 

4 . 1 dpgrotri spc4 . test 

4 . 1 dpgrotrispc64 . test 

4.1 dpgrotrispcS . test 

4.1 dpgrotrspcl2 8 . test 

4.1 dpgrotrspcl6 . test 

4.1 dpgrotrspc2 . test 

4 . 1 dpgrotrspc3 2 . test 

4 . 1 dpgrotrspc4 . test 

4 . 1 dpgrotrspc64 . test 

4 . 1 dpgrotrspc8 . test 

7.1 dpgselect8spc . test 

1 . 3 dpgsete . test 

1.2 dpgsetespcl6 . test 
1 . 2 dpgsetespc32 . test 
1.2 dpgsetespc4 . test 
1 . 2 dpgsetespc64 . test 
1.2 dpgsetespc8 . test 
1 . 2 dpgsetge . test 

1.1 dpgsetgespcl6 . test 

1.1 dpgsetgespc32 . test 

1 . 1 dpgsetgespc4 . test 

1 . 1 dpgsetgespc64 . test 

1 . 1 dpgsetgespcS . test 

1.2 dpgsetl.test 

1.1 dpgsetlspcl6 . test 

1 . 1 dpgsetlspc32 . test 

1.1 dpgsetlspc4 . test 

1.1 dpgsetlspc64 . test 

1 . 1 dpgsetlspc8 . test 

1.3 dpgsetne . test 

1 . 2 dpgsetnespcl6 . test 
1.2 dpgsetnespc32 . test 
1 . 2 dpgsetnespc4 . test 
1.2 dpgsetnespc64 . test 
1.2 dpgsetnespc8 . test 
2.2 dpgset short . test 

1 . 2 dpgsetuge . test 

1.1 dpgsetugespcl6. test 

1.1 dpgsetugespc32 . test 

1 . 1 dpgsetugespc4 . test 

1.1 dpgsetugespc64 . test 

1.1 dpgsetugespcS . test 

1 . 2 dpgsetul . test 

1.1 dpgsetul spcl 6 . test 

1.1 dpgsetul spc32 . test 

1.1 dpgsetul spc4 . test 

1.1 dpgsetul spc64 . test 

1.1 dpgsetulspc8 . test 

7.1 dpgsfli4mxspc. test 
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17.1 dpgsf lxspc.test 
2.1 dpgshf tshort . test 
1 . 3 dpgshl . test 

1.3 dpgshli.test 

7.1 dpgshlispcl28 . test 

1 . 3 dpgshlispclS . test 

2 . 1 dpgshlispc2 . test 

1.3 dpgshlispc32 . test 

1 . 3 dpgshlispc4 . test 

1 . 3 dpgshlispc64 . test 

1 . 3 dpgshlispc8 . test 

7.1 dpgshlspcl28 . test 

1.3 dpgshlspci6 . test 

2 . 1 dpgshlspc2 . test 

1.3 dpgshlspc32 . test 

1 . 3 dpgshlspc4 - test 

1 . 3 dpgshlspc64 . test 

1 . 3 dpgshlspc8 . test 

1.3 dpgshr.test 

1 . 3 dpgshri . test 

7.1 dpgshri spcl2 8 . test 

1.3 dpgshrispcl6 . test 

2 . 1 dpgshrispc2 . test 

1 . 3 dpgshrispc32 . test 

1 . 3 dpgshrispc4 . test 

1 . 3 dpgshrispc64 . test 

1.3 dpgshrispc8 , test 

7.1 dpgshrspcl28 . test 

1 . 3 dpgshrspcl6 . test 

2 . 1 dpgshrspc2 . test 

1.3 dpgshrspc3 2 . test 

1 . 3 dpgshrspc4 . test 

1 . 3 dpgshrspc64 . test 

1.3 dpgshrspc8 . test 

7.1 dpgshuf f leispc . test 

1.3 dpgsub.test 

2.1 dpgsutaspcl6 . test 

2.1 dpgsubspc32 . test 

2 . 1 dpgsubspc4 . test 

2 . 1 dpgsubspc64 . test 

2 . 1 dpgsubspcS . test 

7 . 1 dpgtr8muxspc . test 

2 . 2 dpgucompress . test 
2 . 2 dpgucompressi . test 
2.1 dpgucompressispcl . test 
2.1 dpgucompressispcl 6 . test 
2.1 dpgucompressispc2 . test 
2.1 dpgucompressispc32 . test 
2 . 1 dpgucompressi spc4 . test 
2 , 1 dpgucompressi spc 64 . test 
2 . 1 dpgucompressi spc 8 . test 
2 . 1 dpgucompressspcl . test 

2 . 1 dpgucompressspcl 6 . test 

2 . 1 dpgucompressspc2 . test 

2 . 1 dpgucompress spc 3 2 . test 

2.1 dpgucompress spc4 . test 

2.1 dpgucompress spc64, test 

2 . 1 dpgucompress spc 8 . test 

7 . 2 dpgudepispc . test 

17 . 2 dpgudepixspc . test 
2 . 2 dpguexpand . test 

2 . 2 dpguexpandi . test 

2 . 1 dpguexpandi spc 1 . test 

2 . 1 dpguexpandi spcl6 . test 

2 . 1 dpguexpandispc2 . test 

2 . 1 dpguexpandi spc 3 2 . test 

2 . 1 dpguexpandi spc 4 . test 
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2.1 

dpguexpandispc64 . test 

2.1 

dpguexpandispc8 . test 

2.1 

dpguexpandspcl . test 

2.1 

dpguexpandspcl 6 .test 

2.1 

dpguexpandspc2 .test 

2.1 

dpguexpandspc32 .test 

2.1 

dpguexpandspc4 . test 

2.1 

dpguexpandspc64 . test 

2.1 

dpguexpandspc8 . test 

12 .2 

dpguextractspcl28 . test 

1.3 

dpgumul . test 

1.1 

dpgumuladdl6 . test 

1.1 

dpgumuladd32 . test 

1.1 

dpgumul add4 .test 

1.1 

dpgumuladd64 . test 

1.1 

dpgumuladd8 . test 

1.1 

dpgumuladspcie . test 

1.1 

dpgumuladspc32 .test 

1.1 

dpgumuladspc4 . test 

1.1 

dpgumuladspc64 . test 

1.1 

dpgumul adspc 8 .test 

1.2 

dpgumulspclS . test 

1.2 

dpgumulspc32 . test 

1.2 

dpgumul spc 4 .test 

1.2 

dpgumulspc64 . test 

1.2 

dpgumulspc8 . test 

1.3 

dpgushr.test 

1.3 

dpgushri . test 

7.1 

dpgushrispcl28 . test 

1.3 

dpgushrispcl6 . test 

2 . 1 

dpgushrispc2 . test 

1.3 

dpgushri spc 3 2 .test 

1.3 

dpgushrispc4 . test 

1.3 

dpgushrispc64 . test 

1.3 

dpgushrispc8 . test 

7.1 

dpgushrspcl28 . test 

1.3 

dpgushrspcl6 . test 

2.1 

dpgushrspc2 - test 

1.3 

dpgushrspc32 . test 

1.3 

dpgushrspc4 . test 

1.3 

dpgushrspc64 . test 

1.3 

dpgushrspcS . test 

7.2 

dpguwthispc .test 

17.2 

dpguwthixspc . test 

7.2 

dpgwthispc . test 

17.2 

dpgwthixspc . test 

12 .1 

dpgxlushort . test 

1.2 

dpgxnor.test 

2.1 

dpgxnorspc . test 

1.2 

dpgxor . test 

2.1 

dpgxorspc.test 

1.9 

genasm.pl 

1.7 

genmac .pi 

1.3 

genmacasm.pl 

6.2 

ios 

6 . 1 

loop . file 

1.11 

ntestmac.pl 

1.7 

parse_log.pl 

Dir 

euterpe /verify/ standalone/dr 

1.1 

Makefile 

1 . 1 

dr . conf ig . h 

1.1 

drtester .V 

1.1 

drtester ,h 

Dir 

euterpe /ver if y/standalone/ef 

1.1 

chkmatch 
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1.1 del_line 

1.1 efgfadd32 

1.1 efgfsub32 

1.1 genasm.pl 

1 . 1 genmac . pi 

l.l ntestraac.pl 

Dir euterpe/verify/ standalone/ ef/coonen BOM 2.0 

1 . 1 c_f add 

1 . 1 c_f mal 

1 . 1 c_f ma 2 

1 . 1 c_fraa3 

1.1 c_£msl 

1 . 1 c_f ms2 

1 . 1 c_f mul 

1.1 c_fsub 

Dir euterpe/verify/ standalone/el BOM 2.0 

l.l Makefile 

1 . 1 chkmatch 

1 . 1 del_line 

1.1 elgfaddl6 

1.1 elgfmullS 

1.1 elgfmuladdl6 

1 . 1 elgfmulsubl6 

1.2 elgfshortl6 
1.1 elgfsublS 

1 . 1 genasm.pl 

1.2 ntestmac.pl 

Dir euterpe/verify/standalone/el/coonen BOM 2 . 0 

1 . 1 c_f add 

1 . 1 c_fmal 

1 . 1 c_f ma 2 

1 . 1 c_f ma3 

1 . 1 c_f msl 

1 . 1 c_f ms2 

1 . 1 c_f mul 

1.1 c_f sub 

Dir euterpe/verify/standalone/em BOM 3.0 

1.4 Makefile 

1.1 chkmatch 

1.3 del_line 

1 . 2 emeexpand 
1 . 2 emeshl 

1 . 2 emeshli 

1.2 emeshort 

1 . 2 emeshr 

1 . 2 emeshri 

1 . 2 emeushr 

1 . 2 emeushrx 

1 . 3 emgcompress 
1.3 emgcompressi 
1 . 3 emgcopy 

1 . 3 emgdeal 

1 . 3 emgexpand 

1 . 3 emgexpandi 

1 . 3 emgshl 

1 . 3 emgshl i 

1 . 3 emgshort 

1 . 3 emgshr 

1 . 3 emgshr i 

1 . 3 emgshuf f le 

1 . 3 emgswap 

1 . 3 emguexpand 

1 . 3 emguexpandi 
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1 . 3 emgushr 

1.3 emgushri 

1.3 genasm.pl 

1.3 ntestmac.pl 

Dir euterpe/verify/standalone/et BOM 2.0 

l.l . checkoutrc 

1.1 Makefile 

Dir euterpe/verify/standalone/hc BOM 10.0 

1.37 Makefile 

1.24 NOTES 

8 . 6 addrhex_gen . c 
8 . 1 addroct_gen . c 

5 . 1 addrs . h 

1.2 btob.vec 

2 . 4 btob2 . vec 
8.1 btobstomp. vec 
7 . 1 bug3_gen . c 
1.1 bwfast_gen.c 
8 . 1 checkresults 

7.11 clkregress.pl 

8.1 config.file 
8 . 4 conf lict2 .pi 

2 . 1 conf lict_gen. c 

5.2 event.pl 

5.7 evnt8.vec 

5 . 3 evnt8mix_gen. c 

5 . 1 evnthex.vec 
5 . 2 evntrd. vec 

7.2 fillfifo.pl 
8 . 1 gaunt let . vec 
2.1 he . h 

1.1 he 0_laddr . vec 

1.1 hcl_2addr .vec 

1.8 hc__device.V 
2 . 9 hc_drive . V 

2 . 1 hc_drive . h 

2.2 hc_periph.V 

4.4 hcregress 

8 . 2 hex3 stor_gen . c 

5 . 1 hexratic_<jen . c 

8 . 1 hiaddr . vec 

5.2 hi cup. vec 

5 . 1 ileave2xl_gen . c 

5 . 4 ileave2x2_gen. c 

5 . 1 ileave2x4_gen . c 

8.1 lateenbl.pl 

2.3 lg.vec 

4 . 5 lgrant . vec 

8.1 lisabug.vec 

2.3 mult spa ce_gen. c 

1.3 nb.h 

8.3 nb_pri_6.vec 

1.47 nbhc_drive.V 

1 „ 7 nbhc_dr ive . h 

5 . 12 nbheregress 

5 . 1 octhex_gen . c 

2.2 onechan.vec 

7 . 3 parseout 

8 . 1 perf _dr_hi_gen . c 

8.1 perf_gen.c 

8 . 1 shortratio_gen . c 

8.2 s imphex . vec 

8.2 startup.pl (Attic) 

8.2 stomp, vec 

8 . 6 stompratio_gen . c 
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5 . 2 sustain. vec 

1 . 1 twochan_gen . c 

5.4 vectools.c 

1.1 xfilt.awk 

Dir euterpe/verify/standalone/hcpll BOM 5.0 

1.2 . checkoutrc 

1.4 Makefile 

3.2 clean-request 

1.3 hcpll.pl 

Dir euterpe/verify/standalone/if e BOM 5.0 

4.1 . checkoutrc 
1.12 Makefile 

1.5 brhextest.S (Attic) 

1.6 brimmbktest . S (Attic) 

2.2 brimmlongtest .S (Attic) 

1.6 brimmtest.S (Attic) 

1.7 brpctest.S (Attic) 
2.2 brpctest2.S (Attic) 

1 . 4 brpipetest . S (Attic) 
1.4 brpipetest2.S (Attic) 
1 . 4 brpipetest3 . S (Attic ) 
1.4 brpipetest4.S (Attic) 

1 . 4 brpipetestS . S (Attic ) 

1.5 brregtest.S (Attic) 

3 . 1 clean-request 

Dir euterpe/ verify/ st andalone/io BOM 5.0 

1.5 Makefile 

1 . 2 NOTES 
1.1 clkgen.V 

1 . 1 equaldrive . V 

1 . 1 iobyte . V 

1 . 1 skewer .V 

1.1 tester. V 

1.14 verdrive.V 

1.4 verilog. log.gz 

Dir euterpe/verify/standalone/ld BOM 18 . 0 

1.1 . checkoutrc 
1.24 Makefile 

8 . 2 branch.pl 

8 . 5 clean-request 
1.7 ldaops .pi 
10.1 ldcarry.pl 
13.1 ldrandom.pl 
1.5 ldshift.pl 

1.3 ldshort.pl 

13 . 1 randombranch.pl 

11.2 randomshift.pl 
13.1 shell. S 

Dir euterpe/verify/standalone/nb BOM 2.0 

1.10 Makefile 

1.11 NOTES 

1 . 5 TESTS . doc 

1 . 2 bw_gen . c 

1.1 dr_pri_l.vec 

1 . 1 dr_pri_gen . c 

1 . 1 hex3 chan_l 6_gen . c 

1 . 1 hex3 chan_8_gen . c 

1 . 1 hex3 stor_gen . c 

1 . 1 hexratio_gen . c 

1 . 2 hratiol_gen. c 

1.3 raultild.vec 
1.1 nb.h 
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1.1 nb.toplevel.ut 

1.1 nb.ut 

1.27 nb_dr ive . V 

1 . 1 nb_drive . bak 

1 . 1 nb_drive . h 

1 . 1 oneld_16_gen. c 

1.2 oneld_8_gen. c 

1.10 periph.V 
1.1 periph.new 
1.1 regress 
1.1 tags.vec 

1 . 1 threechan_gen. c 

1 . 3 twochan.vec 

1 . 2 twochan_gen . c 

1.2 vecgen (Attic) 

1 . 7 vecgen . c 

Dir euterpe/ verify/ standalone/uu BOM 17.0 

2.1 . checkoutrc 

8.1 .cvs ignore 
1.62 Makefile 

2.7 bback.S (Attic) 

6.7 bgatei.S (Attic) 

6.2 blink. S (Attic) 

8.5 cerbrupttest.S (Attic) 

6.6 clean- request 

7.5 exlOtest.S (Attic) 

7.3 exlOtest_V.graat 

7 . 3 exlOtest^V. gmsk 

7 . 2 exlOtest_V.gxor 

7.4 exlltest.S (Attic) 
10 . 1 exlltest2 . S (Attic) 

8 . 5 exl5test . S (Attic ) 

7.3 ex9test.S (Attic) 
7 . 1 ex9test_V . gmat 

7 . 1 ex9test_v.gmsk 

7.1 ex9test_V.gxor 

6.4 exaligneasy. S (Attic) 
6.4 exalignharder.S (Attic) 
6.4 exaligntest.S (Attic) 

2.2 exfixeasy.S (Attic) 

2.2 exf ixhandler .S (Attic) 
6.4 exgenhandler . s (Attic) 
3.1 exhandler.S (Attic) 

8.4 exlocktest.S (Attic) 

2.6 exmaskeasy . S (Attic) 

2 . 9 exmasktest . S (Attic) 

2 . 11 exmasktest2 . S (Attic ) 

2 . 10 exmasktest3 . S (Attic) 
2 . 9 exmasktest4 . S (Attic) 

2.6 exmasktest 5. S (Attic) 

6.3 exopaligneasy.S (Attic) 

1.7 expctest.S (Attic) 
8.1 exrleasy.S (Attic) 
5.6 exregeasy.S (Attic) 

2 . 5 exresbminortest . S (Attic) 
6.3 exrescruel.S (Attic) 

2.6 exreseasy.S (Attic) 
8.1 exresedepitestl.S (Attic) 
8.1 exresedepitest2 .S (Attic) 
8.1 exreseradepitestl . S (Attic) 
8 . 1 exreseradepitest2 . S (Attic) 
2.6 exreserainortest . S (Attic) 
8.1 exreseudepitestl.S (Attic) 
8.1 exreseudepitest2 . S (Attic) 
8.1 exreseuwthitestl.S (Attic) 
8.1 exreseuwthitest2.S (Attic) 
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(8.1 

exresewthitestl . S 

(Attic) 

8.1 

exresewthitest2 . S 

(Attic) 

11.1 

exresg_12 8test . S 

(Attic) 

11.1 

exresg_16test . S 

(Attic) 

11.1 

exresg_ltest . S 

(Attic) 

11.1 

exresg_2test . S 

(Attic) 

11.1 

exresg_32test . S 

(Attic) 

11.1 

exresg_4test.S 

(Attic) 

11.1 

exresg_64test . S 

(Attic) 

12 .1 

exresg_8test . S 

(Attic) 

8.1 

exresgcmpritestl . S 

(Attic) 

8.1 

exresgdepitestl . S 

(Attic) 

8.1 

exresgdepitest2 . S 

(Attic) 

8.1 

exresgexpitestl . S 

(Attic) 

8.1 

exr e sgmdep i t e s t 1 . S 

(Attic) 

8.1 

exresgmdepitest2 . S 

(Attic) 

8.1 ' 

exresgmshritestl . S 

(Attic) 

8.1 

exresgrotritestl . S 

(Attic) 

8.1 

exresgshlitestl . S 

(Attic) 

8.1 

exresgshritestl . S 

(Attic) 

8.1 

exresgucmpritestl . S 

(Attic) 

8.1 

exresgudepitestl . S 

(Attic) 

8.1 

exresgudepitest2 . S 

(Attic) 

8.1 

exresguexpitestl . S 

(Attic) 

8.1 

exresgushritestl . S 

(Attic) 

8.1 

exresguwthitestl . S 

(Attic) 

8.1 

exresguwthitest2 . S 

(Attic) 

8.1 

exresgwthitestl . S 

(Attic) 

8.1 

exresgwthitest2 .S 

(Attic) 

2.3 

exreshandler . S 

(Attic) 

2.4 

exreslminortest . S 

(Attic) 

2.7 

exresmaj or . S 

(Attic) 

6.6 

exresregeasy.S 

(Attic) 

2.5 

exressminortest . S 

(Attic) 

2 .11 

extimertest . S 

(Attic) 

2.8 

extimertest2 . S 

(Attic) 

2.10 

privnumtest . S 

(Attic) 

8.4 

ruptpintest . S 

(Attic) 

8.2 

ruptpintest . sen 

(Attic) 

1.6 

thcylnumtest . S 

2 . 2 

thcylnunites t2 . S 

(Attic) 

2.18 

thexheader . S 

(Attic) 

1.4 

thheader . S 

(Attic) 

Dir 

euterpe/verify/tools 

BOM 12.0 

3.8 

cmpregcommit 


3.1 

cmpregend 


3.3 

levelcommit 


3.5 

likelevellog 


5.1 

raergesections 


3.1 

parsecommit 


8.3 

parselikedriver 



suxdinz tegs 


7.1 

stbash 


5.12 

st gen 


Dir 

euterpe/verify/tools/el 

BOM 28.0 

1.4 

. checkoutrc 


1.15 

Makefile 


1.25 

apd2macl . c 


1.63 

apd2resl . c 


1.2 

chk_res . c 


1.10 

chkans . c 


1.2 

chksdq . c 


1.1 

f ilestuf f .h 


1.1 

fp.h 


1.1 

fpsdq. c 
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1.1 fpsdq.h 

1.2 h2doll.c 
1.1 hex2dollar.c 
6 . 4 karztest . c 
1.1 libapd.a 
1.1 libapd.h 
1.1 libsdq.a 

1.1 mak.lib 

1.2 mydecls.h 

1 . 18 newchkans . c 

1.10 opdrvr.c 

1 . 2 opgen . c 

1 . 1 opgen . h 

1 . 1 sdq . c 

1.1 sdq.h 

7.2 splitnshift.pl 

9.1 splitnshiftflags.pl 

1.1 ver_fl.c 

Dir euterpe/verify/tools/ld BOM 21.0 

1.10 aopslib.cpp 

1 . 2 bigext . cpp 
S.2 eugen.pl 

3.11 eulib.cpp 

17.1 ocandromld 
4 . 10 oconlyld 

1.1 pad.pl 

19.2 realld 

1 . 2 unpad .pi 

Dir euterpe/verify/tools/regdepend BOM 26.0 

1.1 . checkoutrc 

1.4 Makefile 
1.29 regdepend . c 

Dir euterpe/verify/toplevel BOM 41.0 

3.1 . checkoutrc 

26.3 . cvs ignore 
1.171 Makefile 

33 . 2 addrsplus8 . S 

30.2 bdownharder . S 

5 . 5 branch . S 

35.3 brcrosstest.S 
30.1 brhermes . S 

31 . 1 brhermesshort . S 
3 5.1 brimmlongtest . S 

35.2 briramlongtest2 . S 
30.2 brmisseasy.S 
31.1 brmisseasy.cti 

28.4 brmisstest . S 
31.1 brmisstest . cti 

30.1 brpcrupt.S 

30.2 brpcrupt2 . S 

3 0.3 brpcrupt3.S 
30.1 brpcrupt3 .cti 
16.4 cache. m 

19.1 cache_V.m 

33 . 4 cache_debug . sig 

35.1 cachesyncheasy . S 

5.2 cd_debug.srl 

7 . 6 cerb_registers . S 

4 0.1 cerbarbdatatest . S 
35.1 cerbcache.S 

19.1 cerbconf ig . S 

9.3 cerbeasy.S 
26.1 cerberrtest . S 

7.12 cerberus. S 
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40 

. 1 

cerbillresp . S 

12 

. 2 

cerbload . S 

40 

. 1 

cerbparerr.S 

22 

. 4 

cerbraw. S 

32 

. 1 

cerbraweasy . S 

24 

.3 

cerbstarttest . S 

34 

. 1 

cerbtorom . S 

39.2 

cerbtotest . S 

7.6 

clean- request 

7.' 


clear. S 

26 

. 2 

clear_0 . loop 

33 

. 2 

cnf lct_debug. sig 

32 

. 1 

colli sion_debug. srl 

30 

,2 

commit . sig 

24 

.3 

commit . srl 

24 

3 

conf igl .m 

27 

1 

crcol.sig 

5.1 

crcol_guts_debug . srl 

30 

. 2 

cruptharder.S 

30 

. 1 

cruptharder . cti 

11 

. 3 

cystoreload. S 

39 

. 1 

dbuf _debug . sig 

15 

. 3 

dcache.tn 

23 

. 8 

dcacheannoying . S 

33 

. 3 

dcacheannoying2 . S 

11 

. 13 

dcacheeasy . S 

11 

. 2 

dcacheeasy . ctd 

13 

. 2 

dcacheeasy . cti 

18 

. 1 

dcacheeasy_V . gmat 

18 

. 1 

dcacheeasy_V . gmsk 

18 

. 1 

dcacheeasy_V. gxor 

15 

.10 

dcacheharder . S 

31 

.4 

dcacheharder2 . S 

31 

. 1 

dcacheharder2_V . gmat 

31 

. 1 

dcacheharder2_V. gmsk 

31 

. 1 

dcacheharder2_V\ gxor 

31 

.4 

dcacheharder3 . S 

31 

.1 

dcacheharder3_V. gmat 

31 

1 

dcacheharder3_V\ gmsk 

31 

1 

dcacheharder 3_V. gxor 

31 

4 

dcacheharder4 . S 

33 

3 

dcacheharderS . S 

33 

2 

dcacheharder6 . S 

35 

2 

dcacheharder7 . S 

35 

1 

dcacheharder8 . S 

18 

1 

dcacheharder_V. gmat 

18 

. 1 

dcacheharder_V . gmsk 

18 

. 1 

dcacheharder_V. gxor 

31 

. 3 

dcachenoalloc . S 

31 

. 1 

dcachenoalloc . ctd 

15 

. 1 

default . ctd 

15 

. 1 

default . cti 

15 

. 3 

default .gmat 

15 

.3 

default. gmsk 

15 

. 3 

default. gxor 

8.3 

defer, s 

26 

.2 

def er_0 . loop 

26 

. 5 

doubleextest . S 

33 

. 1 

doubleextest2 . S 

26 

. 5 

doublemctest . S 

39 

. 2 

dr_debug . sig 

7.8 

dram . S 

7.5 

dram . m 

27 

. 1 

dram_conf igO . conf ig 

27 

. 1 

dram_conf igl . conf ig 

7.4 

dram_debug . srl 

7.7 

drameasy . S 
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31.4 

dramex . S 

7.5 

dramharder . S 

11.4 

dramload . S 

35.1 

drampartial . S 

11.3 

dramprint . s 

31.3 

dramprint harder . S 

33.3 

dramprint harder 2 . S 

33.1 

dtag debug . sig 

24.1 

dtag_storeeasy . S 

7 .4 

e short . S 

33 .1 

eu.config 

33 .1 

eu. ctd 

33 .1 

eu, cti 

26.3 

eu . f mt 

2.3 

eu . in 

33 .1 

eu . loop 

2.3 

eu . sen 

27 .1 

eu. sig 

2.6 

eu. srl 

26.3 

eu.vec 

5.1 

eu_barrelO . srl 

30.1 

eu_debug . sig 

5.9 

eu_debug . srl 

26.5 

eventdaemoneasy . S 

26.6 

eventdaemontest . S 

35.4 

exlltest3 .S 

35.6 

exlltest4 ,S 

35.1 

exhancache . S 

35.2 

exmaskatomic.S 

35.2 

expgcross . S 

35.3 

f rz_debug . sig 

32 .1 

ggf muldep . S 

7.8 

gtlb.S 

7.7 

gtlbaccessl . S 

22 .1 

gtlbaccessl_V.graat 

22 .1 

gtlbaccessl_V . gmsk 

22.1 

gtlbaccessl_V . gxor 

7.15 

gtlbaccess2 .S 

22.1 

gtlbaccess2_V . groat 

22.1 

gtlbaccess2_V . gmsk 

22.1 

gtlbaccess2_V . gxor 

7.14 

gtlbaccess3 . S 

22 .1 

gtlbaccess3_V . graat 

22 .1 

gtlbaccess3_V. grask 

22 .1 

gtlbaccess3_V. gxor 

26.4 

gtlbaccess4 . S 

26.1 

gtlbaccess4_V. graat 

26.1 

gtlbaccess4_V. grask 

26,1 

gt lbacces s4_v . gxor 

7.5 

gtlbeasy . S 

7.13 

gtlbmisseasy . S 

22 .1 

gt lbmi s s ea sy_V . gma. t 

22 .1 

gt lbmi s s easy_V . grask 

22.1 

gt lbmi s s ea sy_V . gxor 

39.1 

heldback_debug . sig 

7.8 

hermes . S 

35 .2 

hermes_Il . S 

35.1 

hermes_I2 . S 

35.2 

hermes_I4.S 

35.2 

hermes_I_store_unique . S 

35.3 

hermes_Ibash . S 

7.9 

hermes_debug . srl 

2.1 

hermes_idles . loop 

32.1 

hermes_lateturnon. S 

8 . 7 

hermeseasy.S 

35.2 

hermeseasy_IlMO . S 

33 .1 

hermesharder . S 
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32.3 

hermesload. S 

35.2 

hermesmc . S 

35.1 

hermesmc . hconf ig 

39.3 

hermnasty__debug . srl 

39.2 

hermtotest.S 

39.1 

hermtotest . hconf ig 

14.2 

ibuf _s tore easy . S 

39.2 

ibuf hz_debug . srl 

33.2 

icache4k.S 

26.6 

icacheannoying . S 

28.1 

icacheannoying . cti 

18.9 

icacheeasy.S 

16.4 

icacheeasy . cti 

16.2 

icacheeasy_V. graat 

16.2 

icacheeasy_v.grask 

16.2 

icacheeasy_V. gxor 

23 .5 

icacheharder . S 

23 .1 

icacheharder . cti 

33.2 

icacheharder2 . S 

33.3 

icacheharder3 . S 

18.1 

icacheinit . S 

27.6 

icachemiss . S 

27.1 

icachemiss . cti 

33 .4 

icachenoalloc , S 

35.2 

if e_debug . sig 

39.1 

if e_debug . srl 

35.2 

if ill_debug. sig 

26.4 

iorupttest .S 

37.2 

isotest . S 

14.1 

itag_storeeasy . S 

8.6 

knobeasy . S 

8.6 

knobharder . S 

37.4 

latedirty.S 

5.3 

lbranch.pl 

27.4 

likedriverlog. sig 

7.12 

likedriverlog. srl 

6 . 12 

load . S 

26.1 

loop . file 

7 . 9 

ltlb.S 

19.1 

ltlbeasy.S 

35.2 

ltlbga.S 

33.3 

ltlbtran.S 

39.2 

lva_debug. sig 

40.2 

mc_debug. sig 

6.4 

meratest . S 

7 . 5 

memtesteasy . S 

39.2 

nb_debug.srl 

11.2 

nbfulltest .S 

35.2 

nbhilotest.S 

31.2 

nbhiprio . S 

31.1 

nbhiprio_V . gmat 

31.1 

nbhiprio_V . gmsk 

31.1 

nbhiprio_V . gxor 

37.2 

nbsmalltest . S 

26.3 

nbuseeasy , S 

35.3 

nbusemul . S 

33.2 

ovf loaduse.S 

27.2 

pagesize . S 

28.1 

pagesizeharder . S 

35.1 

pll.lO.lO.S 

35.1 

pll.S 

33.7 

prblm_deb-ag . sig 

35.2 

preem_debug. sig 

19.1 

priv . S 

39.1 

readdaemon . S 

5.2 

reg_barrelO_debug. srl 

5.1 

reg_debug . srl 
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8.2 

register . S 

8.2 

rf .S 

24.2 

romeasy . S 

24 .3 

rorastarttest . S 

23 .3 

romtest . S 

30.2 

saaseasy . S 

28.3 

saastest . S 

6.2 

save . S 

6.1 

save . sen 

39.1 

scasdep. S 

30.2 

scaseasy.S 

30.3 

scastest . S 

11.1 

shell. S 

2.4 

short . S 

33 .4 

snake_debug . sig 

7 . 5 

snoop . S 

7 . 5 

store. S 

7 .14 

store_unique . S 

27 .2 

storeloadeasy . S 

26.2 

synchtest . S 

32.1 

tag_loadeasy . ctd 

35.2 

tagaccess . S 

33.2 

taghz_debug .sig 

1 .108 

template 

2 . 8 

testl.S 

8.4 

testlO . S 

8 .2 

testll.S 

8.4 

testl2 . S 

11.2 

testl3.S 

11 .2 

testl4.S 

25.1 

testl5.S 

24.1 

testl6.S 

2 .12 

test2.S 

2 . 6 

test3.S 

5.7 

test4.S 

5.8 

test5.S 

5.8 

teste. S 

5.10 

test7 .S 

5.6 

test8 . S 

8 .2 

teat9.S 

2.2 

tieof f . sen 

35.1 

trgt_debug . sig 

30.2 

uncrupt . S 

31.2 

uncrupt2 . S 

30.3 

uncruptharder . S 

5 . 1 

uu2_debug . srl 

5 . 9 

uu_debug . srl 

39.1 

uunb_debug . srl 

33.3 

vlduv_debug . sig 

7 . 8 

watchtest . S 

33 .9 

wbck_debug . sig 

30.4 

xresist . S 

Dir 

eut e rpe / ve r i f y / t opleve l / herme s 

1.1 

. checkout rc 

1.1 

..cvs ignore 

1.2 

Makefile 

3 . 1 

clean -request 

1.8 

herme st est . S 

1.1 

hermestest . ctd 

1.1 

hermestest . cti 

1 . 1 

hermestest . gmat 

1.1 

hermestest . gmsk 

1.1 

hermestest . gxor 

Dir 

euterpe/verify/ukernel 

1.1 

. checkoutrc 
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Makefile 


Dir euterpe/verilog BOM 6 . 0 

1.1 . checkoutrc 

1.8 Makefile 

Dir euterpe/verilog/bsrc BOM 345.0 

32.7 .checkoutrc 

73.1 lcesnk.ut 

116-1 ldr_basic.ut 

1.251 Makefile 

1.57 Makefile . share 

40.104 Makefile. tst 

27.43 Makefile, vo 

68.5 a_eut erpe_wrap . parm 

35.7 analog_euterpe . hwc 
183 . 8 c_euterpe_wrap .parm 
231.5 c_euterpe_wrap .parm . alt 
312.20 chip_eut erpe-base.net cap 
307.11 chip_euterpe-base.nof 
312.23 chip_euterpe-base .pim 

312 . 20 chip_euterpe-base . strength 

307.11 chip_euterpe-base.xrf 

35.8 clockbias .hwc 

168.1 corridor . obs 
304 . 14 cust_intf . wkz 

68.3 d_euterpe_wrap . parm 

80.5 dcells.pif 
7.1 doexcldlist 
80.1 dummy . rc f 

3 0 8.2 e_jtinemo_wrap . vhdl 

6.42 9 euterpe. V 

12 . 6 euterpe . conf ig 
24,77 euterpe . status 
6.76 euterpe_driver . V 

194 . 1 euterpe_known_ w problems 

6.31 euterpe_pads . V 

15 . 100 euterpe_wrap . V 

15 . 4 euterpe_wrap . parm 
134 . 4 export_obs 
119.4 expor t_subblock 
20.1 fake.pl 

284.2 fence. srf 

280.1 geert_v2e.conf ig 
41.20 genpim2.pl 
47.10 gettst 

65.5 h_eut e rpe_wr ap . p a rm 
12.1 hwcnets 

3 08.2 i_euterpe_mnemo__wrap . tb 

187 . 14 i_euterpe_wrap . tb 

18 7 . 13 i_euterpe_wrap . vhdl 

325.4 i_h_eut erp enwrap . tb 

325.3 i_s_euterpe_wrap . tb 

91.6 levellog 

134.2 levelmlog 
1.18 opchart 

168 . 8 padtiles . ercf 

3 7.8 pimlib.pl 

131.3 preptest 
70.3 purgetst 

131.1 runs 
134.8 runvtest 

240.2 s_euterpe_wrap . parm 
62.10 stashtst 

4 0.4 subblk.rcf 

52 . 5 tbr 3__v2 e . conf ig 

35.3 toplev. power . tab. local 
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41.5 toplev.rcf 

12 . 2 tst_y2e . conf ig 

Dir euterpe/verilog/bsrc/at BOM 93.0 

4.2 . checkout rc 

1.18 Makefile 
1.66 at.V 
1.7 at . h 
51.23 at.pim 

28.8 at . power . tab . top 

1. 3 atcdwe2 .pla 

59.1 atcteql2.V 

1 . 1 atcylenc .pla 

1 . 5 atdisallowxc . pla 

25.3 atgtlbcnf let . Veqn 
1.5 atgtmissxc . Veqn 

44 .4 atillglpa. Veqn 

2.4 atnbreq.Veqn 
1.25 atpadcd.Veqn 

1 . 3 atpaselgen64 . v 

66.2 atpaselgen8 . V 

1 . 19 atprchk . Veqn 
1 . 3 atvabyp . Veqn 

1 . 5 atxcenbl .pla 
1 . 2 atxcf rz . Veqn 

4.11 clean- request 
1.3 genatcteql58.pl 

1.1 genatpasel.pl 

3.12 genpim.pl 

3.2 genptab.pl 

3 . 9 piralib.pl 

Dir euterpe/verilog/bsrc/au BOM 44.0 

14.2 .checkoutrc 
1.11 Makefile 

16.11 au . power . tab . top 

1.24 auindx.V 

12.11 auindx.pim 

14.8 clean-request 

12.5 genpim.pl 
12.1 pimlib.pl 

14 . 4 power . tab . local 

Dir euterpe/verilog/bsrc/cc BOM 92.0 

9.3 . checkoutrc 
1.27 Makefile 
1.87 cc.V 

63.4 cc. flat. pirn 

32.7 cc. power . tab . top 
1.18 cc.ut 

77.8 cc_control_blob.pim 

73 . 3 cc_misc .pirn 
78.1 cc_j?bb.pim 

28.6 cccount,pla 

80 . 1 ccf illcount .pla 
2 8.6 cchexcount .pla 
60 . 3 cchold.Veqn 

4 0.9 cc latedir ty . Veqn 
51.10 ccrcv.Veqn 
28.20 ccseq. Veqn 

24 . 18 ccstart .Veqn 

77.2 ccstart__custom.pim 
1.21 cctester.V 

1.1 cctester.h 

14.13 clean-request 

5.20 genpim.pl 
5.16 pimlib.pl 
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5 . 2 power . tab . local 

Dir euterpe/verilog/bsrc/cdio BOM 55.0 

19.9 . checkoutrc 
1.12 Makefile 
1.20 cdio.V 

34.10 cdio . power . tab . top 
7 . 1 cdio . ut 

28.5 cdio_control .pirn 

25 . 6 clean-request 

7.7 genpim.pl 

3 . 12 genptab.pl 

7.13 pimlib.pl 

Dir euterpe/verilog/bsrc/ce BOM 86.0 

1.17 Makefile 

1.15 Makef ile .gards 

59.1 Makef ile . irsim 

1.1 ce.config 
2.20 ce_cms2ecl.V 

2.19 ce_flash.V 
17.6 ce_kybd.V 

17 . 4 ce_kybdcntr . V 

32.14 ce_mck.V 

2.10 ce_seg7.V 

1 . 6 ceclockbiasbuf . V 
1.24 cecore.V 

1.2 cedmctrl.V 
1 . 4 cedractrlm . V 

1.2 cedractrlt.V 
1 . 9 cedpreg.V 

1 . 1 celoosends . V 

1 . 14 cemaster . V 
1 . 8 cerb . in 

1 . 8 cerbctrlreg . V 
1.58 cerberus.V 
1.31 cerberus . cpif 

1.4 cerberus, rcf 

1.7 c e rbnobr e g . V 

1.6 cerbskewreg.V 

1.9 cerbtempreg.V 
1.44 cerbtest.V 

1.7 ceregbuf.V 
1.43 ceregcore.V 

1.20 ceslave . v 

1.5 cetstmux.V 
77 .4 pimlib.pl 

Dir euterpe/verilog/bsrc/cg BOM 11.0 

1.9 Makefile 

9 . 1 cgclockbias . v . f or_use_with_squelsh_buf f er 

Dir euterpe/verilog/bsrc/cj BOM 121.0 

4 6.5 .checkoutrc 

18.2 libr.ut 

18.2 liss.ut 
1.40 Makefile 
2.14 br.tst 
120.1 brxcdef er . tst 

1.21 cj.V 

1.3 cj.h 
62 . 10 cj .pim 

69.12 cj .power. tab. top 

13.38 cjrst.tst 

48 . 3 clean- request 

1.10 f reel. tst 
42.3 genpim.pl 
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4 7.7 genptab . pi 
11.20 hic.tst 
1.15 hold. tst 
3.19 ifbr.tst 

23.8 ifpred3-ll.tst 

20.7 ifpred3-2 .tst 

5 .26 micbr . tst 
5.15 pcbhnd.tst 
42 . 3 pimlib.pl 
78.12 rsrvd.tst 
93.4 rupt.tst 

Dir euterpe/verilog/bsrc/ck BOM 26.0 

10.4 .checkoutrc 

1.8 Makefile 

9.2 ck.V 

17 . 8 ck. power . tab. top 

1 . 3 cktop . V 

11.1 clean 

12 . 2 clean- request 
10 . 2 genpim.pl 

10.5 pimlib.pl 

Dir euterpe/verilog/bsrc/cp BOM 60.0 

9.4 . checkoutrc 

1.9 Makefile 

9.9 clean-request 
1.36 cp.V 

7.14 cp.pim 

19 . 12 cp , power . tab . top 

41.8 cph.pira 

47 . 4 cphh.pim 

41 . 7 cpl .pirn 

5.11 genpim.pl 

5.4 pimlib.pl 

5 . 15 power . tab . local 

Dir euterpe/verilog/bsrc/ctiod BOM 31.0 

1.4 . checkoutrc 

1.6 Makefile 
7.1 bram.init 

1 . 7 clean-request 
7.1 ctd.in 

1.11 ctiod.V 

12.8 ctiod. power . tab . top 

6.3 ctiod. ut 

1 . 3 ctiodtester . V 

5 . 1 ctiodtester . h 

1 . 3 ctwe . Veqn 

1.1 genpim.pl 

1 . 8 genptab . pi 

1.12 pimlib.pl 

Dir euterpe/verilog/bsrc/ctioi BOM 28.0 

3.2 . checkoutrc 

1.5 Makefile 

4 . 6 clean- request 

1.16 ctioi.V 

1.10 ctioi.pim 

9.9 ctioi. power. tab. top 

1 . 3 genpim.pl 
1.1 pimlib.pl 

4 . 7 power . tab . local 

Dir euterpe/verilog/bsrc/dp BOM 45.0 

1.32 Makefile 

1.40 dp.V 
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dp top . V 

29.4 

dpwrap . V 

13.11 

rastepc . V 

Dir 

euterpe/verilog/bsrc/dr 

32. 6 

. checkoutrc 

1.33 

Makefile 

1.4 

README 

62 . 1 

c2e .pirn 

33.6 

clean- request 

12.1 

clocksub 

1.26 

dr.V 

1.1 

dr . clocks .ut 

1.16 

dr.conf ig.h 

43.6 

dr . power . tab . top 

1.9 

dr.ut 

1.2 

dram . registers 

1.1 

drba . pla 

7.11 

drbank.V 

1.7 

drbankarb.pla 

1.3 

drbankc sm . pi a 

3.6 

drbanksel . Veqn 

64.2 

drbanksel . custom. pira 

67.1 

drbothbanks control .pirn 

1.3 

drcd.pla 

1.2 

drclockphase . pla 

1.3 

drcolscram.pla 

67 . 1 

drcommoncontrol . pirn 

4.4 

drconf ig2bs . pla 

70.2 

drcontrol j unk . pirn 

1.3 

drcsra . states . h 

1.2 

drcsmdecode . pla 

10.5 

dr instantiate. h 

1.3 

droktoact .pla 

1.2 

droktopre .pla 

1.1 

droktoread . pla 

1.3 

droktowrite .pla 

3 .17 

drout.V 

5.5 

droutde2Sel .pla 

72.1 

droutdpcontrol . pirn 

1.4 

drpads .V 

1.2 

drpagecontrolstack . pla 

1.2 

drpagecsm.pla 

1.1 

drpagev .pla 

1.3 

drpmgen.pla 

1.1 

drpop .pla 

3.7 

drprbcsm.pla 

1.3 

drrc .pla 

1.4 

drreadcount . V 

62.1 

drreadcount . pirn 

1.3 

drreadcountsel.pla 

1.3 

drresetseq.pla 

1.3 

drrowscram.pla 

1.1 

drrp .pla 

1.5 

drsamplephase .pla 

1.3 

drseqcheck . pla 

3.1 

drspacematch.Veqn 

6.2 

drtagqc .pla 

1.18 

drtester . V 

1.6 

drtester .h 

1.8 

drtop . V 

27.1 

drtop2 .V 

1.3 

drwritecount .pla 

1.3 

drwritedsel . pla 

20.12 

genpim.pl 

39.2 

genptab.pl 

20.16 

pimlib.pl 
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Dir euterpe/verilog/bsrc/dr/conf ig BOM 2.0 

1.1 Makefile 

1 . 1 drain . datasheet . explained 

1.1 dram. datasheet .nec .10 

1 . 1 dram . datasheet , nec . 12 

1 . 1 dram . system . datasheet 

1 . 1 marg . c 

1.1 system. datasheet .explained 

Dir euterpe/verilog/bsrc/dr/dram BOM 6.0 

1.4 Makefile 
1 . 1 README 

1.1 byl6_64m.ut 

1.1 by8_16m.ut 

1.1 by8_64m.ut 

1 . 1 sdram . V 

1 . 2 sdram . h 

1.1 sdram . small , h 

1 . 1 sdram . ut 

1 . 1 spy . h 

1.3 tester, V 
1.1 tester. h 

Dir euterpe/verilog/bsrc/dr/dram/mit BOM 4.0 

1.3 Makefile 

1.1 mi tsubishi. sdram. model 

1.1 op . v 

1 . 1 sdram . v 

Dir euterpe/verilog/bsrc/drio BOM 26 . 0 

3.5 . checkoutrc 
1.5 Makefile 

5.4 clean-request 

1.2 drio.V 

20.5 drio . nearpads .pirn 
9.11 drio . power . tab . top 
1.4 genpim.pl 

1.2 pimlib.pl 

1 . 3 power . tab . local 

Dir euterpe/verilog/bsrc/es BOM 97 . o 

45.3 .checkoutrc 
1.23 Makefile 

45 . 15 clean- request 

5.4 6 es.V 
5.55 es.pim 

65 . 12 es .power . tab. top 

40.10 es_xlu.V 

1.18 esaddbyt.V 

60.6 esaddby ta . V 
60.5 esalmsum.V 

60.4 esalmsumb.V 
1.29 esalu64.V 
1.10 escla.V 
1.8 9 escntrl.V 
1.29 esomux.V 

I. 4 estop. v 
37.14 genpim.pl 
37.1 pimlib.pl 

13 . 7 power . tab , local 

Dir euterpe/verilog/bsrc/gf BOM 37.0 

II. 4 . checkoutrc 
1.16 Makefile 

11.8 clean- request 
9.8 genpim.pl 
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1.7 gf .V 

4.15 gf.pim 

19.9 gf . power . tab . top 
1.3 gfbit.pla 

1.11 gfbyt.V 

1.1 gftop.V 

9.1 pimlib.pl 

Dir euterpe/verilog/bsrc/gt BOM 98.0 

3 9.5 . checkoutrc 

8.3 2gtlb.ut 

9.4 3gtltgtlb.ut 

1.2 9 Makefile 
41.8 clean- request 
26.8 genpim.pl 

14 . 3 genpipedat . pi 

24 . 8 genptab.pl 
7 . 15 gentst .pi 
2.28 gt.V 

54.10 gt. power .tab. top 

2 5.21 gt_control . pira 

7.25 gt_driver.V 

9.5 gtdone.pla 

10 . 12 gtinstantiate . h 

7.4 gtrdy.pla 
7.41 gtsnake.V 

7 . 5 gtsnakemuxctl .pla 

7 . 7 gtspraatchearly . Veqn 

7.24 gt spina tchlate . Veqn 

7 . 4 gtwe . Veqn 
26.23 pimlib.pl 

Dir euterpe/verilog/bsrc/hc BOM 124.0 

35.10 . checkoutrc 

1.30 Makefile 

40 . 7 clean- request 

34.6 genpim0.pl 

3 2.10 genpiml.pl 
12.5 gentst.pl 
1.56 hc.V 

3.15 hc.h 

8.5 he . ut 

68 . 9 he 0 .power . tab. top 
73.25 hcO_control .pirn 

68.9 he 1 .power . tab. top 
73.15 hcl_control .pirn 
65.3 hc_brresp.pla 
6.2 hc_cmp6.V 

27.17 hc_control . pirn 

8.10 hc_device.V 

3 . 16 hc_dr iver . V 

4 . 2 hc_error . Veqn 
12.3 hc_fifo8.V 

12 . 3 hc_f ifo8ctrl . Veqn 

3 . 26 hc_ostate .pla 
3 . 15 hc_j?arse . Veqn 
3 . 13 hc_jprbctrl . pla 

3 . 3 hc_rxcrc . Veqn 
75.2 hc_sadrsel . Veqn 
3 . 13 hc_sdecode . Veqn 
3.13 hc_sid.Veqn 

3 . 5 hc_tagmatch . V 

3 . 2 hc_txcrc . Veqn 

13.1 he instantiate.]! 

27.10 pimlib.pl 

17.7 power . tab . local 
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Dir euterpe/verilog/bsrc/hz BOM 30.0 

4.3 . checkoutrc 

1.5 Makefile 

4 . 5 clean-request 

4 . 6 genpim.pl 
1.15 hz.V 

9.8 hz.pim 

10.8 hz . power . tab . top 

1.1 hz.ut 

1.3 hzmatch.V 

1.7 hztester.V 

1.2 hztester.h 
4.2 pimlib.pl 

4 . 2 power . tab . local 

Dir euterpe/verilog/bsrc/icc BOM 4 9.0 

15.4 . checkoutrc 
1.6 Makefile 

3.4 genpim.pl 
1.45 icc.V 

2.6 icc.h 

3 9.5 icc.pira.txt 

19 . 7 ice. power . tab. top 

16 . 15 icc_control .pirn 

15 . 10 iccinhife. Veqn 

1.9 iccxcie.Veqn 
1.13 iccxci7.Veqn 

3 . 6 pimlib. pi 

39.2 power . tab- local 

39.1 txt2pim.pl 

Dir euterpe/verilog/bsrc/if e BOM 68.0 

18.3 . checkoutrc 
4.2 1 . ut 

1.13 Makefile 

18 . 5 clean-request 

15 . 7 genpim.pl 
1.2 if.h 

1.9 ifbr.tst 

1.45 ife.V 

61.2 ife.pim.txt 

4 0.5 if e . power . tab . top 
15 . 14 if e_control .pim 

1.7 iffree.tst 

1.5 iffrees.tst 

1.5 ifhold.tst 

1.9 ifpcselil .Veqn 
2 . 12 if rst . tst 

1.2 ifwntdi3 .Veqn 

1.10 ifwntdi4 . Veqn 

28.1 ifwntdiS .Veqn 

15.4 pimlib.pl 

15.2 power. tab. local 

Dir euterpe/verilog/bsrc/io BOM 48.0 

9.6 . checkoutrc 
1.18 Makefile 

9.8 clean- request 
8.6 genpim0.pl 

8 . 5 genpiml . pi 

47.1 getSpiceNets 

24.8 ioO .power . tab. top 
22 . 10 io0_control .pim 
24.8 iol. power. tab. top 

22.6 iol_control.pim 

31.2 io_buf_8.v 
6.4 io_if if o. V 
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6.1 io_iphase.Veqn 

6.1 io_ofifo.V 

6.1 io_ophase.Veqn 

6 . 2 io_sciof f_6 . V 
6.1 io_scioff_9.V 

3.1 iocount.pla 

3 . 2 iodrive . V 
3.1 iofs.Veqn 

3 . 12 iorate.V 

46.2 netcap_getSpiceNets.txt 

4.9 piralib.pl 

7 . 4 power . tab . local 

Dir euterpe/verilog/bsrc/iq BOM 67.0 

22.4 . checkoutrc 
12.2 l.ut 

1.38 Makefile 

24.8 clean- request 

20 . 9 genpim.pl 
1.33 iq.V 
61.2 iq.pim 

50.6 iq. power . tab. top 

20.17 iq_control.pim 

2 . 7 iqbr.tst 

1.10 iqfree.tst 

1.8 iqfreeS.tst 

1.10 iqhold.tst 

1.11 iqholdS.tst 

1 . 1 iqholdq2 . Veqn 

1.5 iqholdqq. Veqn 
3 . 1 iqpredq4 . Veqn 

9.4 iqrst.tst 

20.5 pimlib.pl 

20.2 power . tab . local 

Dir euterpe/verilog/bsrc/lt BOM 98.0 

56.3 . checkoutrc 

3.3 0 Makefile 

56.6 clean-request 
56.6 genpim.pl 
56.2 genptab.pl 
3.72 lt.V 

68.12 It . power . tab . top 

56.19 lt_control.pim 

90.1 ltmiss.Veqn 

7.8 ltstldenbl.Veqn 

56.14 pimlib.pl 

Dir euterpe/verilog/bsrc/mc BOM 79.0 

17.4 . checkoutrc 

1.21 Makefile 
17.19 clean- request 
13 .17 genpim.pl 

1.22 mc.V 

38.6 mc . control .obs 

48.8 mc . control .pim 

4 8.9 mc . dataHigh . pim 
4 8.7 mc. dataLow . pim 
6.24 mc.pim 

37.11 mc. power. tab. top 

14.31 mc_xluc.V 

28.4 mc_xlud.V 

1 . 6 mcacc8 . V 

1.5 mcaddbyt.V 

1.1 mcadf32.v 
1.11 mcalu64.V 

1.2 mccla.V 
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1 13 .2 pimlib.pl 

j 16 . 4 power . tab . local 

|D±r euterpe/verilog/bsrc/mg BOM 51.0 

|14 .3 lstr.ut 

|1.32 Makefile 

1 1.1 dee. in 

1.1 dco . in 

1.3 mg . h 

8.28 mgrst.tst 

1.23 rslt.tst 

10.10 str.tst 

Dir euterpe/verilog/bsrc/rast BOM 3 8.0 

13.3 . checkoutrc 

I. 16 Makefile 

13 . 10 clean- request 

II . 6 genpim.pl 

20.1 msaccl6.V 
1.1 msadf32,V 
1 . 6 msbooth. V 

20 .2 mscsaddlSa. V 
20.2 mscsaddl6b.V 
20.2 mscsaddl6e . V 

1.3 mshotc.V 

20.1 mshotca.V 

20.2 msinl6a.V 

20.1 msinl6b.V 

20.2 msrcdie.V 
20.1 msrcdl6a.V 
20.1 msrcdl6b.V 
1.11 mst.V 

2.18 mst.pim 

23.9 mst .power . tab. top 

1.1 rastop.V 

11.1 pimlib.pl 

Dir euterpe/verilog/bsrc/nb BOM 13 0.0 

46.7 .checkoutrc 

1.45 Makefile 

1 . 4 README 

46.7 clean-request 

31.19 genpim.pl 

52 . 6 genptab.pl 

1.4 muxffl7_l.V 

1.4 muxffl7_4.V 

1.2 muxffl7_5.V 
1.79 nb.V 

31.10 nb.h 

82 . 12 rib . power . tab . top 

31.4 nb. toplevel .ut 

14.11 nb.ut 

88 .16 nb_Tnid.pira 

88.15 nb_top.pim 

9.19 nbal6xS4 . tpl 
31.22 nbctrl . Veqn 
9.19 nbd32x64.tpl 
1.13 nbfq.V 

44.4 nbf qcount .pla 

1.3 nbfqprienc.pla 

1 . 5 nbfqslice.pla 

44.3 nbfulllp .pla 
90 . 2 nbgotorie . v 

90.2 nbgotones lice .Veqn 
12.2 nbholdoff .pla 

68 .1 nbholdoff 3 .pla 

1.13 nbperiph.V 
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1.13 nbpq.V 

1 . 3 nbpqhelper .pla 

1 . 3 nbpqptrbitO .Veqn 

1 . 5 nbpqptrslice . Veqn 

7 . 5 nbprbarb . Veqn 

7 . 2 nbprbcount . pla 

1.5 nbrq.V 

1 . 3 nbrqptrbito . Veqn 

1 . 3 nbrqptr slice. Veqn 
1.52 nbtester.V 

1.8 nbtester.h 

8 . 5 nbvd.pla 
15.7 nbwe.Veqn 
12 0.1 nbwed . Veqn 
31.15 pimlib.pl 

Dir euterpe/verilog/bsrc/nb/rf BOM 5 . 0 

1.4 Makefile 

I. l rf.ut 

I I. 4 rflrlw.V 

11. 1 rflrlwl6wx64b.h 

1.1 rflrlw32wx64b.h 

1.1 rftester.V 

1 . 1 rf tester . h 

Dir euterpe/verilog/bsrc/periph BOM 8.0 

1.6 Makefile 
1 . 1 README 

1.1 p.ut 

3 .2 sptest.ut 

Dir euterpe/verilog/bsrc/rf BOM 3 . 0 

1.2 l.tst 

1.7 Makefile 

1.3 dor f spy 
1 . 2 drvchk . V 
1.6 rf_l,V 

1.5 rf_5.V 

1 . 3 rf_dec . Veqn 

1.2 run.V 

1.2 spy.V 

Dir euterpe/verilog/bsrc/rg BOM 136.0 

60.3 . checkoutrc 

14 . 1 lbr . ut 

14.2 le.ut 

14 . 3 lmul . ut 
1.50 Makefile 
60.12 clean- request 
19.14 genpim.pl 

82.4 genptab.pl 
19.23 pimlib.pl 
29.17 rg.V 

82 .31 rg.pim 

79. 12 rg. power . tab. top 

67 . 4 rg_control .pirn 

1.12 rgcr.V 

1.20 rgdp.V 

1 . 7 rgimm . V 

1.33 rgpc.V 

52.2 rgplrO.pla 

9.28 rgrst.tst 

1.15 rslt.tst 

Dir euterpe/verilog/bsrc/rgxtnit BOM 42.0 

1.5 . checkoutrc 

1.4 Makefile 
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8.5 clean-request 

1.3 genpim.pl 

1.1 pimlib.pl 

1 . 1 power . tab . local 
1 . 3 rgpcbrr7 . Veqn 

1 . 3 rgwewk . Veqn 

1 . 24 rgxmit . V 

19.6 rgxmit . power . tab . top 

1.16 rgxmit_control . pim 

Dir euterpe/verilog/bsrc/sr BOM 75.0 

24.7 . checkoutrc 
1.21 Makefile 

26 .11 clean-request 
16.14 genpim.pl 
27.7 genptab . pi 

16.12 pimlib.pl 
2.3 2 sr.V 

3.5 sr.h 
51.12 sr. pim 

39.10 sr .power . tab. top 

1 . 2 sr_cla.Veqn 

16 . 21 sr_control . pim 

1 . 9 sr_driver .V 

3 .3 sr_eventl6.Veqn 

3 . 4 sr_eventreg.V 
16.5 sr_eventr eg .pim 

3.6 sr_evmaskl6 .v 
41.2 sr_hcevent . V 
1.3 sr_inc4.pla 

1 . 3 sr_inc4a .pla 

2.4 sr_match.V 

11.1 sr_mcho Id . Veqn 
3 . 3 sr_radecode . pla 
1.3 sr_timer.V 

16.2 sr_tiraer .pim 

3 . 3 sr_wadecode .pla 

Dir euterpe/verilog/bsrc/tst BOM 111.0 

13.2 le.ut 

13 .3 libr.ut 

13.2 liss.ut 

13.3 11. ut 

13.2 lpc.ut 
13.1 lq.ut 
13.1 lstr.ut 
1.24 Makefile 

1.10 br.tst 
1.84 drvcnk.V 

70.3 ic.tst 

6.4 0 job.tst 

1.11 rslt.tst 
1.29 rst.tst 

1.17 spy.V 
3 . 8 tstgen 

6 . 35 tstrst .tst 

3 . 2 vervars 
3 . 4 vew 

3 . 1 vlwire 

Dir euterpe/verilog/bsrc/uu bom 217.0 

79.4 . checkoutrc 
25.1 l.ut 

25.1 le.ut 

25.2 limm.ut 
25.2 1 immpc . ut 
25.1 liss.ut 
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25.1 

lnb.ut 

25.1 

lpc .ut 

1 . 79 

Makefile 

2 .14 

br. tst 

78.9 

clean- request 

174.1 

cmp_res .pi 

131.9 

evblm . prio 

174.2 

gen_mem . pi 

68.17 

genpira.pl 

68.14 

pimlib.pl 

81.2 

power . tab . local 

125.7 

sswap. tst 

169.4 

sswap8 . tst 

180.1 

uu-local-p4 . obs 

123.4 

uu- local. obs 

1 .200 

uu.V 

1.37 

uu.h 

119.13 

uu . power . tab . top 

68.60 

uu_control . pirn 

174.3 

uu_dr ive . V 

1.23 

uubruv . tdcd 

1.13 

uubruw.Veqn 

1.20 

uubypltncyuv . tdcd 

1.4 

uuchkdstr3 . Veqn 

1.10 

uu chkd s tuw . Ve qn 

112.1 

uucmp2rn. V 

1. 11 

uudstselut . tdcd 

1 . 9 

uuf ree. tst 

1.15 

uuhold. tst 

1.19 

uuholduu . Veqn 

1 .20 

uuimmpc . tst 

1.32 

uuimmpcut . tdcd 

24.12 

uuimmus . tdcd 

1. 14 

uuisdstuv . tdcd 

1.1 

uuisdstuvsplit 

1.24 

uuissrcur . tdcd 

28.10 

uuj oblstux . Veqn 

63 .15 

uumemuv . tdcd 

8 . 15 

uuraic . tst 

8 . 12 

uumicut . tdcd 

9.8 

uuraicuu . tdcd 

112 .3 

uuovrlyregreg . V 

156.2 

uuovrlysrcdstcyl . pim 

36.17 

uuprblmf rz . Veqn 

108.6 

uuprblmrO . Veqn 

108.6 

uuprblmrlO , Veqn 

50.10 

uuprblmrll . Veqn 

50.8 

uuprblmrl2 . Veqn 

60.11 

uuprblmrl3 .Veqn 

50.11 

uuprblmrS . Veqn 

50.1 

uuprblmr6 . Veqn 

107.12 

uuprblmr7 . Veqn 

50.14 

uuprblmr8 . Veqn 

61.15 

uuprblmr9 . Veqn 

32.15 

uuprblmup . Veqn 

50.19 

uuprblmwm . Veqn 

14.35 

uupr eemuq . Veqn 

1.2 

uupsi.pla 

8 . 3 

uurbuu.Veqn 

15.11 

uur s ltbypcuu . Veqn 

1. 20 

uursltbypuu. Veqn 

28.10 

uursrvd. tdcd 

170.4 

uursrvduu . tdcd 

170.2 

uursrvduv.pla 

170 . 1 

uursrvdwd.pl 

15.30 

uurst . tst 

53.2 

uurstuq.pla 
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76.5 uuruptrl2 . Veqn 

84 . 7 uusteput , pla 

84 . 16 uustepuu.pla 

1 . 16 uuthruus . tdcd 

1 . 14 uuthruut . Veqn 
1 .2 uuwewj .Veqn 

Dir euterpe/verilog/bsrc/xlu bom 65.0 

28.3 .checkoutrc 
1.48 Makefile 

8 . 1 TODO 
25.1 cl.srf 
25.1 c2.srf 
26.1 C3.srf 

36.1 clean- request 

25.1 cs2 . srf 

25 . 1 cs3 . srf 

23.2 db_7a.srf 
21.5 dc_8a.srf 
8 .21 genpim.pl 

22 . 4 misc2 . srf 

22 . 3 misc3 . srf 
8 .20 piralib.pl 

35 . 1 power. tab. local 

21.4 q_9a_7.srf 
19.14 route.pl 
33.9 xl23.pim 

4 0.2 xl26.pim 

33.3 x456.pim 
25.1 xbus.srf 
24.9 xlu.V 

14 .4 xlu.mpc 
35.1 xlu.nets 

33.1 xlu.noflip 

62.2 xlu.pim 

4 8.4 xlu. power . tab. top 

17.5 xlu.rcf 
33.7 xlu4 . obs 

39.1 xlu6.obs 

41.2 xlu_add4.V 

1 . 16 xlu_ctrldata . c 

1.2 xlu_la_r2.c 

18.2 xlu_sr.c 
28.1 xlu_sr_c3 . dir 

28.3 xlu_sr_r2 . dir 
28.1 xlu_sr_r3 . dir 
6.2 xlu_tr_sl.c 
28.1 xlu_tr_sl . dir 
6.2 xlu_tr_s2.c 
28.1 xlu_tr_s2 . dir 
6.2 xlu_tr_s3.c 
26.1 z3.srf 

25.1 zs3.srf 

Dir euterpe/verilog/bsrc/yy BOM 26.0 

1.15 Makefile 
1.2 dob2dascii 
2.2 dotestassign 
1.24 tas.pl 

2.1 test.V 

1.1 yy.h 

1 . 5 yyunasm . V 

1.5 yyunasmmnesel . tdcd 

1 . 5 yyunasmmusel . tdcd 

Dir euterpe/verilog/lvs BOM 3 . 0 

1.8 Makefile 
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1 . 2 l_eut erpe_wrap . parm 

Dir euterpe/verilog/lvs/enetlib BOM 2.0 

1.1 . checkout rc 

1,1 Makefile 

===> running euterpe/ . checkout rc (Fri Aug 11 23:10:42 PDT 1995) <=== 
gmake -G ged default 

gmake [1]: Entering directory "/N/auspex6/sl0/chip/euterpe/ged' 
for LIB in ' ' toplevel rf ; do \ 

if [ -z " $LIB" ] ; then continue; fi; \ 

if [ ! -f $LIB/$LIB. lib 3 ; then \ 
mkdir -p $LIB; \ 

echo 'FILEJTYPE - SPICE_DIR; ' > $LIB/$LIB . lib ; \ 
echo 'END.' » $LIB/$LIB.lib; \ 
fi; \ 

/n/auspex/slO/chip/euterpe/tools/bin/mkgedlib -cluS $LIB; \ 

done 

rm -f tmpfile 

gmake [1]: Leaving directory "/N/auspex6/sl0/chip/euterpe/ged' 
gmake -C compass /layouts default 

gmake [1] : Entering directory * /N/auspex6/ si 0/chip/euterpe/ compass /layout s • 
gmake [1] : Nothing to be done for "default'. 

gmake [1]: Leaving directory * /N/auspex6/ si 0/ chip/ euterpe/ compass/ layout s ' 
gmake -C dcell dcells 

gmake [1]: Entering directory "/N/auspex6/sl0/chip/euterpe/dcell • 
gmake list dcell. topt subcells 

gmake[23: Entering directory "/N/auspex6/sl0/chip/euterpe/dcell • 

gmake[2}: ""list 1 is up to date. 

gmake [2] : "dcell. topt' is up to date. 

gmake [2] : Nothing to be done for "subcells 1 . 

gmake [2] : Leaving directory "/N/auspex6/sl0/chip/euterpe/dcell 1 
gmake [1]: Leaving directory "/N/auspex6/sl0/chip/euterpe/dcell ' 
gmake -C baseplate all 

gmake [1]: Entering directory * /N/auspex6/sl0/chip/euterpe/baseplate ' 
[ -d /n/auspex/ si 0/chip/euterpe/ compass /baseplate ] { | mkdir -p 
/n/auspex/slO/chip/euterpe/compass/baseplate 

| gmake subcells /n/auspex/slO/chip/euterpe/compass/baseplate/padtext . ly 
/n/auspex/ si 0/chip/euterpe/ compass /baseplate/baseplate . ly\ 
labels 

gmake [2]: Entering directory "/N/auspex6/sl0/chip/euterpe/baseplate 1 
gmake [2]: Nothing to be done for "subcells 1 , 

gmake [2]: " /n/auspex/ si 0/chip/euterpe/ compass /baseplate/padt ext . ly 1 is up to date. 
gmake[2J: "/n/auspex/sio/chip/euterpe/compass/baseplate/baseplate . ly ' is up to date, 
gmake [2] : Nothing to be done for "labels'. 

gmake [2]: Leaving directory " /N/auspex6/sl0/chip/euterpe/baseplate ' 
grep -w mobieclium_site 
/n/auspex/slO/chip/euterpe/compass/baseplate/baseplate_ecl_logic . ly \ 
I grep 11 A R" \ 

I awk ' { sum=sum+$9*$10 } END {print sum, "eclatoras 11 } ' 
430164 eclatoms 

grep -w mosatom_site /n/auspex/slO/chip/euterpe/compass/baseplate/baseplate_mos_logic . ly 

\ 

| grep «*R" \ 

I awk • {sum=sum+$9*$10}END{print sum, "mosatoms " } ' 
77980 mosatoms 

[ -d /n/auspex/sl 0/chip/euterpe/ compass /baseplate ] | | mkdir -p 
/n/auspex/ si 0/chip/euterpe/ compass /baseplate 
gmake /n/auspex/sl 0/chip/euterpe/ compass /baseplate/ stpadtext . ly 
gmake [2]: Entering directory "/N/auspex6/sl0/chip/euterpe/baseplate ' 

gmake [2]: " /n/auspex/ si 0/chip/euterpe/ compass /baseplate/stpadtext . ly 1 is up to date, 
gmake [2]: Leaving directory " /N/auspex6/sl0/chip/euterpe/baseplate 1 
gmake /n/auspex/slO/chip/euterpe/compass/baseplate/spacetrans . ly 
gmake [2]: Entering directory " /N/auspex6/sl0/chip/euterpe/baseplate ' 

gmake [2]: " /n/auspex/slO/chip/euterpe/compass/baseplate/spacetrans . ly ' is up to date, 
gmake [2]: Leaving directory "/N/auspex6/slo/chip/euterpe/baseplate ' 
gmake /n/auspex/sio/chip/euterpe/compass/baseplate/euterpep. ly 
gmake [2]: Entering directory " /N/auspex6/sl0/chip/euterpe/baseplate ' 
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gmake [2]: Vn/auspex/slO/chip/euterpe/compass/baseplate/euterpep . ly ' is up to date, 
gmake [2]: Leaving directory VN/auspex6/slO/chip/euterpe/baseplate ' 
[ -d /n/auspex/slO/chip/euterpe/compass/baseplate ] j | inkdir -p 
/n/auspex/ si O/chip/euterpe/compass /baseplate 
gmake mms . die .pad /n/auspex/slO/chip/euterpe/compass/baseplate/baseplate_padnd_andlbl . ly 
gmake [2]: Entering directory * /N/auspexS/slO/chip/euterpe/baseplate 1 

/n/auspex/ slO/chip/euterpe/ tool s /bin/mk. padl ist . to. mms euterpe -dbu "grep 'units [ 

]*u[ ]*=' f loorplan . sgen . m4 | gawk '{print $NF+o}'" \ 
1 < /n/auspex/slO/chip/euterpe/compass/baseplate/baseplate_jpadnd.ly > mms .die. pad. tmp 
jmv mms. die. pad. tmp mms. die. pad 

| gmake [2]: Vn/auspex/slO/chip/euterpe/compass/baseplate/baseplate_padnd_andlbl . ly ' is up 
to date . 

| gmake [2]: Leaving directory "/N/auspex6/sl0/chip/euterpe/baseplate ' 

| [ -d /n/auspex/ slO/ chip/ euterpe /compass /baseplate 3 | | mkdir -p 

/n/auspex/ si 0 /chip/ euterpe/compass/baseplate 
gmake /n/auspex/slO/chip/euterpe/compass/baseplate/euterpetop. ly 
gmake [2]: Entering directory VN/ auspexS/ si 0/ chip /euterpe /baseplate ' 

gmake [2]: "/n/auspex/slO/chip/euterpe/compass/baseplate/euterpetop . ly ' is up to date, 
gmake [2]: Leaving directory VN/auspex6/s 10 /chip/ euterpe /baseplate 1 
gmake [1]: Leaving directory VN/auspex6/slO/chip/euterpe/baseplate 1 
gmake -C gards all 

gmake [1]: Entering directory VN/auspex6/sl0/chip/euterpe/gards 1 
rm -rf Depend- cdl Depend-pdl 
gmake gards 

gmake [2]: Entering directory VN/auspex6/sl0/chip/euterpe/gards ' 

/n/auspex/slO/chip/euterpe/proteus/gards/Makefile.base: 123 : Depend-pdl: No such file or 
directory 

} /n/auspex/slO/chip/euterpe/proteus/gards/Makef ile. chipbase : 156 : Depend- cdl: No such file 
or directory 

lecho ' ./sofa/sofa_model.cdl.abgen . /sofa/sofa. pdl : \' > Depend-cdl 

I /n/auspex/slO/chip/euterpe/tools/bin/vlsimm -M -p ./sofa -v 

/n/auspex/ si 0 /chip/ euterpe /compass/vl si .boo- dcell sofa_model >> Depend-cdl 

| ERROR -- can't find cell "padcrack_uplay 1 (boo file 

- < . /sof a> : : /n/auspex/slO/chip/euterpe/compass/vlsi . boo-dcell ' ) 

| ERROR -- can't find cell "padseal_uplay 1 (boo file 

"< . /sofa>: : /n/auspex/slO/chip/euterpe/compass/vlsi .boo-dcell 1 ) 

| ERROR -- can't find cell "padm' (boo file 

"< . /sof a> : : /n/auspex/slO/chip/euterpe/compass/vlsi .boo-dcell ' ) 
echo 1 ' >> Depend-cdl 

### making dependencies Fri Aug 11 23:12:42 PDT 1995 
# 

# leafmold cells 
# 

echo ' LEAF_CELLS = \' > Depend-pdl 

sed 's/.*/ & \\/; $s/\\//' /dev/null » Depend-pdl 

echo ' 1 >> Depend-pdl 

for cell in "cat /dev/null * ,- do \ 

echo "/$cell.pdl: \\" >> Depend-pdl; \ 

/n/auspex/sl0/chip/euterpe/tools/bin/sun4/vlsimm -M -v 
/n/auspex/slO/chip/euterpe/compass/vlsi. boo-dcell $cell >> Depend-pdl; \ 

echo ' » >> Depend-pdl; \ 

done 
# 

# sofa-based custom cells 
# 

echo 'SOFA_CELLS = \ ' » Depend-pdl 

sed 's/.*/ & \\/; $s/\\//' /dev/null » Depend-pdl 

echo ' 1 >> Depend-pdl 

for cell in *cat /dev/null do \ 

echo " . /sof a/$cell.pdl: \\» » Depend-pdl; \ 

/n/auspex/slO/chip/euterpe/tools/bin/vlsimm -M -v 
/n/auspex/slO/chip/euterpe/compass/vlsi. boo-dcell $cell >> Depend-pdl; \ 

echo ' ' >> Depend-pdl; \ 

done 
# 

# full custom cells 
# 
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echo ' CUSTOM_CELLS = \' » Depend-pdl 

sed 's/.*/ & \\/; $s/\\//' /dev/null » Depend-pdl 

echo * 1 >> Depend-pdl 

for cell in "cat /dev/null do \ 

echo w /$cell.pdl: \\" >> Depend-pdl; \ 

/n/auspex/slO/chip/euterpe/tools/bin/vlsimm -M -v 
/n/auspex/slO/chip/euterpe/compass/vlsi.boo-dcell $cell >> Depend-pdl; \ 

echo 1 ' >> Depend-pdl; \ 

done 
# 

# dummy cells 
# 

echo ' DCELL_CELLS = \ ' >> Depend-pdl 

sed ' s/.*/ & \\/; $s/\\//' /dev/null /n/auspex/slO/chip/euterpe/dcell/list >> Depend- 
pdl 

echo 1 1 >> Depend-pdl 

for cell in "cat /dev/null /n/auspex/slO/chip/euterpe/dcell/list " do \ 

echo " ,/dcell/$cell.pdl; /n/auspex/slO/chip/euterpe/compass/dcell/$cell . ly' r >> 
Depend-pdl ; \ 
done 

### finished making dependencies -- Fri Aug 11 23:12:45 PDT 1995 
gmake [2]: Leaving directory VN/auspex6/slQ/chip/euterpe/gards ' 
gmake [2] : Entering directory " /N/auspex6/sl0/chip/euterpe/gards ' 
gmake [2 J: *** No rule to make target K _MISSING_LAYOUT_FILE_» , needed by 
"sof a/sof a_model . cdl .abgen' . Stop. 

gmake[2]: Leaving directory VN/auspex6/slO/chip/euterpe/gards ' 
gmake [1]: *** [all] Error 2 

gmake [1] : Leaving directory VN/auspex6/slD/chip/euterpe/gards ' 
gmake: *** [euterpe] Error 2 

[finished at Fri Aug 11 23:19:21 PDT 1995 -- exit status 2] 


' \1 


Exhibit C17 


Page 87 of 148 


From: vanthof (vant) 

Sent: Friday, August 1 1 , 1 995 1 2:50 PM 

To: hardheads 

Cc: vanthof (Dave Van't Hof) 

Subject: lower layer edits in euterpe 


Just a little reminder to people working on euterpe layout edits: 

DO NOT CHANGE POLY or below. 
We have now seen occurances where POLY was edited. This is not good. 

We have also seen occurances where instances of poly waffle cells were flattened. Since 
we are not changing poly, This is also forbidden. 

To sum it up: 

- Do NOT change poly 

- Do NOT flatten or change instances which contain poly. 

We have started the tapeout process for the lower layers, therefore any cell with a lower 
layer edit will be reverted and all other edits lost as well. 

Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context." The Tick to Thrackazog 
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From: vanthof (vant) 

Sent: Friday, August 1 1 , 1 995 2:34 AM 

To: tbr (Tim B. Robinson); lisar (Lisa Robinson); geert (Geert Rosseel); hopper (Mark Hofmann); 

jack (Jack Wenstrand) 

Cc: vanthof (Dave Van't Hof); manser (Steve Manser); mouss (John Moussouris); ai (Albert 

Matthews); paulp (Paul Poenisch); anh (Anh Ngo) 
Subject: euterpe lower layer fracture started at 11 :56 pm 8/1 0/95 


The lower drc's for euterpe finished tonight and there were 4 poly spacing errors (1 error 
in 1 cell repeated 4 times) . I fixed this edit, got the update into the snapshot, then we 
started the fracture job for the lower layers. 

This is a new fracture flow, some new tools, and a new chip, so we may end up having to 
restart once or twice. Based on previous tapeouts with the old flow, these layers should 
be done by monday morning. 

I've also started up another fullchip lower drc. The last one took 3.5 days, so this run 
should finish by monday noon, just in time to let us know if the tapes will be good. I 
don't expect any problems though. 

One major caveat. We have not had a clean lvs run in some time. There is still some 
chance that there is a short or bad connection which would force a modification of the 
lower layers. The lvs should finish on Sunday sometime. 

Thanks , 
Dave 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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Sent: 

To: 

Cc: 


Subject: 


From: 


vanthof (vant) 

Friday, August 11, 1995 2:12 AM 
Tim B. Robinson 
vanthof (Dave Van't Hof) 
Re: Back on the air 


Tim B. Robinson writes: 

> 

> I have a full chip lower drc run going and was about to figure out how to 

> restart the fracture stuff Kurt started. He left instructions, so it should 

> be pretty simple. 
> 

>Sounds good. Where are you getting the . ly file from for this 
>fracture? Kurt said we should be using the full euterpe.ly, but 
>obviously even though I can regenerate a new baseplate it will be some 
>time before we have a complete route again to regenerate that file. 

I'm using the snapshot euterpe layouts (and snapshot proteus layouts). 

I was just looking at how the layer id and copyright fit into the die and I'm not sure 
it • s quite right yet . There is base poly from the layer id and copyright overlapping 
n+poly from the die. Base poly is the same as p+poly so in effect we have n+poly and 
p+poly overlapping. We really only create on poly mask, and it's the implants that 
determine the type. I'm not sure what will happen in this areas. This may have been the 
intended effect, I don't know and will have to ask Dan. 

We may have to restart the fracture in the morning, but that would put us on schedule. 
The fact that I started it tonight means we are effectively ahead of schedule by about 12 
or 24 hours. 


> I'll send out some status pretty soon. 
> 

>Good. We should let people know we are right on track to get the tapes 

>out by 8/14 . 

> 

>Tim 


Okey dokey. 
Dave 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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Sent: 

To: 

Cc: 


Subject: 


From: 


tor 

Friday, August 11, 1995 1:59 AM 
vanthof (vant) 
vanthof (Dave Van't Hof) 
Re: Back on the air 


vant wrote (on Thu Aug 10) : 


Tim B. Robinson writes: 
> 

>We have power again. Let me know if you need anything. 

>I'll restart the make, 

> 

>Tim 


Great! I think I have everything under control Thanks! The getbom finished 
and only updated the one layout file like I wanted. 

OK. I'll start the build again. 

I have a fullchip lower drc run going and was about to figure out how to 
restart the fracture stuff Kurt started. He left instructions, so it should 
be pretty simple. 

Sounds good. Where are you getting the . ly file from for this fracture? Kurt said we 
should be using the full euterpe.ly, but obviously even though I can regenerate a new 
baseplate it will be some time before we have a complete route again to regenerate that 
file. 

I'll send out some status pretty soon. 
Good. We should let people know we are right on track to get the tapes out by 8/14. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


jack (Jack Wenstrand) 

Thursday, August 10, 1995 12:17 PM 

for 

euterpe 

Layout Review, 8/10/95 


Tim, 


Thank you for the suggestion. Will do! I've posted recent review minutes directly to 
the Euterpe news group for the record, and with this message, I forward yesterday's 
minutes to Euterpe list. 
Regards , 
Jack 

> Date: Wed, 9 Aug 1995 21:44:27 -0700 

> From: tbr (Tim B. Robinson) 

> References: <199508100125.SAA15922@orion.microunity,com> 


> Given the large distribution already for this mail, I think it would 

> be good to copy ' euterpe r . Not only would this show the rapid 

> progress being made to a wider audience, it would also become part of 

> the permanent record because mail to euterpe gets archived in a news 

> group. 
> 

> Tim 


Subject: Layout Review of 8/9/95 


1. Next meeting: Thursday, 8/10, 3pm, Multimedia room. 

2. Action items from last time, for Thursday: 
Review of scribe lines, cell f0007 

- Beware of contact pedestal crossing iso. 
The following actions should be complete for a 
review of this cell on Thursday. 

* Dan: 

* Fill in SDEC, being careful not to short e-test 
patterns. Do not fill alignment marks. 

* Remove silicide, disconnecting these structures 
to prevent shorts. 

* Invert metals. Blocks of metal are preferred to 
perforations . 

* Std. size vias centered on the metal blocks would 
work well for the via layers. 

* Paul: verify no short to die across crack-protect 

ring after SDEC fill. 

* Johnny: Verify no e-test structure shorts after 

SDEC fill. 

* Johnny: Unstack metal layers. Make them lum wide, 

like Pollux. Replace the cranklation with long 
straight bars of metal . 
-pads : 

* Johnny: Add via45 to assist probability. 0 . 7um 

sq. , < 10% density. 

3. SDEC Status: (Geert) proceeding on track. 

4. Pad Review (Paul) cell padttl 

Excellent progress. No problem with areas reviewed 
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today. With Mike's and Orlando's help, Paul expects 
to be ready for the final pad review tomorrow. 

5. PLL/bias generation cell pl_eus 

- Ml edge is centered on contact pedestal. This is 
permitted by design rules, but difficult to 
manufacture . 

* Chris Michael: Has bjt285 been simulated? Please 
talk to Al about this oft repeated transistor. 

- Several Metal issues were noted, common to many 
analog blocks, as follows. These issues occur in 
many places . This problem has been added to the 
"Priority List for Major Changes" below. No work 
should be done on these issues until the earlier 
major issues on that list have been addressed. 

. Use 2.5um or 4 . Sum lines/1. 5um spaces in M3 for power 

strapping in analog blocks. 
. Change via23 to meet the compromise design 

rules. 

. Change M2 to 1.2 5 line/. 75 space parallel lines 

for shielding. 
. Where M3 is used for shielding, widen the metal 

and orient the lines orthogonal to M2 . 

6. ABS Plan. 

Decision: we will not tape out or do the backend- 
processing for the ABS layers for the 
initial metal tapeout . The will 
accelerate matters considerably. If we 
later choose to go back for ABS, we will 
need to replace the M3 mask. 

7 . Next steps . 


Future Schedule: 
Thursday 

memory cell(s) review 
final pad metal review 

test structures, pmosl, nmosl, bjti, 
(single level ring counter?) 

Friday 

wafflizer review 

scribe-line fill f0007. Changes from Tuesday, 
+ waf flized metal 

Monday Review Baseplate DRCs 

Review additional analog blocks. 

Priority List for Major Changes (above the line in process) : 

1. SDEC 

2. Revise pad and seal ring. 


3 . Redo vial2 on atom powerbus for damascene process . 

4. Alter M2/via23/M3 per notes of 8/9. 

Wait List 

-epllsofa: Stacking of metals and via sizing will need 
some adjustment. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


torn (Tom Laidig [tau]) 

Wednesday, August 09, 1995 9:27 PM 

Kurt Wampler 

tau; geert (Geert Rosseel); hopper (Mark Hofmann); solo (John Campbell); vanthof (Dave 
Van't Hof) 

Re: SDEC/ContPed fixes 


Kurt Wampler writes: 

I've checked- in and released the edits I made to the domain control 
blocks and their subcells. There are many DRC flags around the edges 
of these cells because they're not clean without the rest of the clock 
spar interface cells that form their context. I believe I have fixed 
all the real DRC flags, but some more may crop up when they are 
combined at the next higher level. Since I will be out Thursday 
morning and all day Friday (due to a death in the 
family) I thought I would check 'em all in; if there are problems 
someone else may want to fix them rather than wait for my return. I 
hope I didn't make anything worse. 

Thanks, Kurt -- I think we can take care of any remaining DRVs. I think tomorrow 
afternoon we ' 11 need for you to focus on preparing us to do the tapeout of the lower 14 
layers of euterpe. I believe we intend to start the fracture process Friday afternoon {or 
whenever we think we're finished fixing all lower- layer DRVs that we see from the 
currently- running DRC) . Hopefully the fracture will finish on Monday. 
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From: jack (Jack Wenstrand) 

Sent: Wednesday, August 09, 1995 8:25 PM 

To: al; geert; paulp; hopper; vanthof; torn; anh; jack; rich; ong 

Cc: mouss; tony; manser; wingard; mudge; cadettes; fung; kumar; tomb; yao; rip; to; ted; ky; liang; 

hoov; trancy; linden; anderson; alves; graham; dane; yves; ras; torn ho; michael; solo; tbr; tony 
Subject: Layout Review of 8/9/95 


1. Next meeting: Thursday, 8/10 , 3 pm, Multimedia room. 

2. Action items from last time, for Thursday: 
Review of scribe lines, cell f0007 

- Beware of contact pedestal crossing iso. 
The following actions should be complete for a 

review of this cell on Thursday. 

* Dan: 

* Fill in SDEC, being careful not to short e-test 
patterns. Do not fill alignment marks. 

* Remove silicide, disconnecting these structures 
to prevent shorts. 

* Invert metals. Blocks of metal are preferred to 
perforations . 

* Std. size vias centered on the metal blocks would 
work well for the via layers. 

* Paul: verify no short to die across crack-protect 

ring after SDEC fill. 

* Johnny: Verify no e-test structure shorts after 

SDEC fill. 

* Johnny: Unstack metal layers. Make them lum wide, 

like Pollux. Replace the cranklation with long 
straight bars of metal, 
-pads : 

* Johnny: Add via45 to assist probability. 0.7um 

sq. , < 10% density. 

3. SDEC Status: (Geert) proceeding on track. 

4. Pad Review (Paul) cell padttl 

Excellent progress. No problem with areas reviewed 
today. With Mike's and Orlando's help, Paul expects 
to be ready for the final pad review tomorrow. 

5. PLL/bias generation cell pl_eus 

- Ml edge is centered on contact pedestal. This is 
permitted by design rules, but difficult to 
manufacture . 

* Chris Michael: Has bjt285 been simulated? Please 
talk to Al about this oft repeated transistor. 

- Several Metal issues were noted, common to many 
analog blocks, as follows. These issues occur in 
many places . This problem has been added to the 
"Priority List for Major Changes" below. No work 
should be done on these issues until the earlier 
major issues on that list have been addressed. 

. Use 2.5um or 4 . 5um lines/1. 5um spaces in M3 for power 

strapping in analog blocks. 
. Change via23 to meet the compromise design 

rules . 

. Change M2 to 1.25 line/. 75 space parallel lines 

for shielding. 
. Where M3 is used for shielding, widen the metal 

and orient the lines orthogonal to M2 . 
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6. ABS Plan. 

Decision: we will not tape out or do the backend- 
processing for the ABS layers for the 
initial metal tapeout . The will 
accelerate matters considerably. If we 
later choose to go back for ABS, we will 
need to replace the M3 mask. 

7 . Next steps , 


Future Schedule: 
Thursday 

memory cell (s) review 
final pad metal review 

test structures, pmosl, nmosl, bjtl, 
(single level ring counter?) 

Friday 

wafflizer review 

scribe-line fill f0007. Changes from Tuesday, 
+ waf flized metal 

Monday Review Baseplate DRCs 

Review additional analog blocks. 

Priority List for Major Changes (above the line in process) : 

1 . SDEC 

2. Revise pad and seal ring. 


3. Redo vial2 on atom powerbus for damascene process. 

4. Alter M2/via23/M3 per notes of 8/9. 

Wait List 

-epllsofa: Stacking of metals and via sizing will need 
some adjustment. 
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Sent: 

To: 

Cc: 


Subject: 


From: 


hopper (Mark Hofmann) 

Wednesday, August 09, 1995 6:47 AM 

Robert E. Van Cleef 

sysadm; vant; tau 

Re: bizarre problems with hestia? 


Robert E, van cleef writes: 

Hestia should be ok for now. The problem was a core file in / which 
placed the partition over 104%. The midnight rdist from cronus ended 
up truncating the passwd file - grabbing a chunk out of the middle - 
leaving it without Dave's account and no entry for root. 

We need to insure that the current root partition is clean and lay plans 
for reconfiguring the system with a larger partition. 

We need to enlarge Hestia' s root partition to prevent a future occurance . 

Yes, good idea. Apparently there are many Sparc 2's with the same anemic root partition 
size (7.4Meg) . This should be beefed up to prevent another Hestia-like debacle. Moving to 
the 4.1.4 release at the same time might be effcient. If this were donw we would need to 
make sure that all the special dirvers- for extra out board disks and tape drives, etc. 
are supported. I worry that it may be difficult to come up with a generic kernel that fits 
all machines. We also would want our original "hostid hack" 

which we use to move a node- locked license from one Sparc 2 to another when a machine is 
sick or goes down. 

I would also recommend that we begin moving all mail reading to gaea. 
It appears that there 

are quite a few users that need to think about moving. . . 

bpw@frodo, craig@mnemosyne, ras@narcissus, gmo@bilbo, 
mikew@euterpe, rich@pegasus , tom@clio, ong@ares, 
vanthofohestia, dicksonOdemeter , jerry@sisyphus, hayes@erato, 
orlando@millennium, jeff ©mercury, vo@merope, ef elias@poseidon, 
dane@marathon, khp@spirot, wampler®thoas , and many, many 
others... about 50% of the Unix users. 

I think this is also a good idea. There is some hesitancy on the part of users because of 
NFS funnies with file locking and mail flakiness in the past. At one point we did not want 
everyone to be logged into the mail machine because it was getting bogged down. But if 
people read their mail remotely there is a finite chance that mail could be lost or, at 
least, placed in an inconsistent state. This has happened in the past. Can we support a 
mail machine? Or can we install some better mail handling system? 

Also, if Hestia is critical, we should add it to the critical machines 
listing so that the admin on duty will be paged. 

I think hestia should be added to the critical machines list. As Dave points out this 
would not have helped here- the machine did not actually crash, it just had a trashed / 
partition. 

Dave is receptive to moving the Dracula license demon to Rhea (with the other demons) as 
long as he can have root access to the machine. I believe he may have Rhea access already. 

So, if we move the license demon off Hestia, enlarge Hestia' s root partition, move mail 
off Hestia and move Dave's directory from Rama to the Auspex, I think we will be in better 
shape. I would say as long as Hestia runs the Dracula demon it should be considered a 
critical machine, and therefore entered into the critical machines list. 


Bob 


- thanks , 
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hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 
Tuesday, August 08, 1995 4:58 PM 
Geert Rosseel 

mikew (Mike Wageman); vanthof (Dave Van't Hof); torn (Tom Laidig) 
Re: pad cells 


Geert Rosseel writes: 

> For the metals, please just take the wide metal that is there and cut it 

> up into strips per Paul's requests. 

We don't need to make any fancy hierarchy 

> or cells. 

I kind of agree with that . It ' s really not the way we normally 
should do things, but I am sure that Al & Paul will make more 
changes to the pads and any hierarchy or nice layout the we 
come up with may be wasted work. 

I suggest we do a fast and not so pretty layout and maybe once it's 
all approved we can go back and make it better. I think in the 
long term we want to make some major changes to the pads anyway . . 
The diodes, the resistors, . . it's all a bit messy . . 


I agree, too. It ' s a sure bet that these pads will be short-lived. Let's do just what 
needs to be done for this tapeout. We will re-visit these pads nex time 'round for the 
next tapeout . 


Geert 


-hopper 
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From: vanthof (vant) 

Sent: Tuesday, August 08, 1995 11:31 PM 

To: Tim B. Robinson 

Cc: torn (Tom Laidig); doi (Derek Iverson); vanthof (Dave Van't Hof) 

Subject: Re: release anomoly 


Tim B. Robinson writes: 
> 

>I'm trying to get a clean bom in the eterpe tree for the next big 
>build. There is something odd in euterpe compass. The top level BOm 
>in euterpe calls out version 4.3 for this, and that is the version in 
>/u/chip. However, according to cvs log, there is a BOM 5.0 which I 
>released (as chip) the last time I was trying to do this. Any idea how 
>this release could have happened without getting propagated to /u/chip? 

Could this have been a result of the /u/chip/mdunit/ . . . disk filling up today? 

Tom went through great effort to rebuild the CVS/Entries files in 3 layout directories, 

one of which was /u/ chip/mduni t /euterpe/ compass/ layouts . 

> 

>The next odd thing is that in the snapshot I did a getbom -m, and got 

>the warning: 

> 

> 

>/n/auspex/s4l/euterpe-snapshot/euterpe/compass : BOM is newer (5.0) than the version 
specified for this directory (4.3) - extraction of this directory tree suppressed. 
> 

>However, if I now look, the BOM itself is 5.0: 
> 

>chip@staypuf t /n/auspex/s4l/euterpe-snapshot/euterpe/compass 8 % more 
>B0M # Created by mkbom # $Id: BOM,v 5.0 1995/07/22 17:14:44 LT chip Exp 

> 

>File 1.9 vlsi. boo-all 

>File 1.8 vlsi.boo-dcell 
>File 1.9 vlsi .boo- tapeout 

> 

>Dir 19.0 BOM layouts 

> 

>even though there are a whole bunch of downrev files: 
> 

>chip@staypuft /n/auspex/s41/euterpe-snapshot/euterpe/compass 7 % cvs -n 

>update cvs update: Updating . 

>cvs update: Updating layouts 

>U layouts/euterpelpadtl.ly 

>U layouts / euterpe lpadt r . ly 

>U layouts/f 0007 . ly 

>U layouts/f 00 07_f ill_ctpg . ly 

>U layouts/f 0007_f ill_ml . ly 

>U layouts/f 0007_fill_m2 . ly 

>U layouts/f 00 07_fill_m3 . ly 

>U layouts/f 00 07_fill_m4 . ly 

>U layouts/f 0007_fill_vl2.1y 

>U layout s / f o o o 7__f i ll_v2 3 . ly 

>U layout s/f 0 o 07_f ill_v34 .ly 

>U layouts/f 00 07_fill_v45 . ly 

>U layouts / 1 id_euterpe_l . ly 

>U layouts/vlsi.cko 

>U layouts/vlsi.log 

> 

>I'm going to assume we want the latest version of all these. 
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Yes, Dan checked these in today for the frame. We will need them. Of course, after the 
design review today, he will need to update them a bit. 

Thanks , 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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From: tbr 

Sent: Tuesday, August 08, 1 995 1 1 :28 PM 

To: torn 

Cc: doi; vanthof 

Subject: release anomoly 


I'm trying to get a clean bora in the eterpe tree for the next big build. There is 
something odd in euterpe compass. The top level BOm in euterpe calls out version 4.3 for 
this, and that is the version in /u/chip. However, according to cvs log, there is a BOM 
5.0 which I released (as chip) the last time I was trying to do this. Any idea how this 
release could have happened without getting propagated to /u/chip? 

The next odd thing is that in the snapshot I did a getbom -m, and got the warning: 


/n/auspex/s4 1 /euterpe- snapshot /euterpe/compass : BOM is newer (5.0) than the version 
specified for this directory (4.3) - extraction of this directory tree suppressed. 

However, if I now look, the BOM itself is 5.0: 

chip@staypuft /n/auspex/s41/ euterpe -snap shot /euterpe /compass 8 % more BOM # Created by 
mkbora # $Id: B0M,v 5.0 1995/07/22 17:14:44 LT chip Exp $ 

File 1.9 vlsi. boo-all 

Pile 1 . 8 vlsi . boo-dcell 

File 1.9 vlsi .boo- tapeout 

Dir 19.0 BOM layouts 

even though there are a whole bunch of downrev files: 

chip@staypuft /n/auspex/s41/euterpe-snapshot/euterpe/compass 7 % cvs -n update cvs update: 
Updating . 

cvs update: Updating layouts 
U layout s / euterpelpadt 1 . ly 
U layouts/euterpelpadtr.ly 
U layouts/f 0007 .ly 
U layouts/f 0007_fill_ctpg. ly 
U layouts/f 0007_fill_ml.ly 
U layouts/f 0007_fill_m2 . ly 
U layouts/f 00 07_fill_m3 . ly 
U layouts/f 0007_fill_m4.1y 
U layouts/f 00 07_f ill_vl2 . ly 
U layouts/f 0007_f ill_v23 . ly 
U layouts/f 0007_f ill_v34.1y 
U layouts/f 0007_f ill_v45 . ly 
U layout s / lid_euterpe_l . ly 
U layouts/vlsi.cko 
U layouts/vlsi.log 

I'm going to assume we want the latest version of all these. 

There are also a couple of BOMs in the verify tree with a similar problem. Again I can't 
explain how they come to be that way. 
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From: solo (John Campbell) 

Sent: Tuesday, August 08, 1995 10:20 AM 

To: vant 

Cc: solo@microunity.com; jack@microunity.com; al (Albert Matthews); geert (Geert Rosseel); 


paulp (Paul Poenisch); hopper (Mark Hofmann); torn (Tom Laidig); anh (Anh Ngo); jack (Jack 
Wenstrand); rich (Rich McCauley); ong (Warren R. Ong); mouss (John Moussouris); tony 
(Tony Stelliga); manser (Steve Manser); wingard (Drew Wlngard); mudge (john mudge); 
cadettes; fung (Fung Chen); kumar; tomb; yao (Henry Yao); rip (Rajiv Patel); to (To Do); ted 
(Ted Chen); ky (K.Y. Ramanujam); liang; hoov (Bill Hooven); trancy (Trancy Tsao); linden 
(Linden Critchlow); anderson; alves (Maria Alves); graham (Graham Y. Mostyn); dane (Dane 
Snow); yves (Jean-Yves Michel); ras (Bob Sutherland); tomho (Tom Ho); michael (Chris 
Michael); tbr (Tim B. Robinson) 
Subject: Re: Euterpe review minutes, 4/7/95 


as vant was saying 

. .John Campbell writes: 
♦ . > 

. . >as Jack Wenstrand was saying 

. , > . . 

. . > . . * John Campbell . Resis cell . Connected properly? 

. . > . . Please check it out and send mail . 

. . > 

. .>This cell, resis. ly was edited on july 14, released on aug 6 and . . >causes all ttl io 
buffers to fail lvs . does someone want to take on . . >the edit of this cell. must be done 
in context of the chip. 
. . > 

. . >my understanding is that the changes were directed by fab so maybe . . >they should 
direct the fixes so we don't unsolve what they were trying . . >to fix. 
. . > 

..>paulp?? maybe. 

..the changes were to comply with what was (at that time) the current metal ..rules. I 
believe the open is simply because the pad metal edits were ..not completed because of new 
information from the fab which invalidated ..much of the work done on the pads at that 
time. However, the lower layer ..edits were required which is why the pads were released. 

..No one seems to understand how this cell works and I must have it completed . . so I can 
start up a fullchip lvs. __If_ I can get an lvs started this morning, . .it is not going to 
be completed until late Saturday, which is over a day ..after the second run of the drc ' s 
will be started. If the lvs comes back . .bad, and it requires lower layer edits, then 
we've just blown the tapeout ..schedule. 

..All I need is a quick fix to make it lvs correct. The metals are being ..completely 
redone, and I'm not going to wait for that to be completed before ..starting the fullchip 
lvs (to verify the lower layers) . 

. .Dave 

it can be lashed together. unlock ttle2teu ttl3vnew and ttle2ttl. 
let's do it. but... lets fix it for real right away. like later today. 

regards, EMail solo@microunity.com 

solo a.k.a. John Campbell phone 4 08 734-8100 fax 4 08 7 34-8136 
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Subject: 


Sent: 
To: 

Cc: 


From: 


vanthof (vant) 

Tuesday, August 08, 1995 10:10 AM 
John Campbell 

jack@microunrty.com; al (Albert Matthews); geert (Geert Rosseel); paulp (Paul Poenisch); 
hopper (Mark Hofmann); torn (Tom Laidig); anh (Ann Ngo); jack (Jack Wenstrand); rich (Rich 
McCauley); ong (Warren R. Ong); mouss (John Moussouris); tony (Tony Stelliga); manser 
(Steve Manser); wingard (Drew Wingard); mudge (john mudge); cadettes; fung (Fung Chen); 
kumar; tomb; yao (Henry Yao); rip (Rajiv Patel); to (To Do); ted (Ted Chen); ky (K.Y. 
Ramanujam); liang; hoov (Bill Hooven); trancy (Trancy Tsao); linden (Linden Critchlow); 
anderson; alves (Maria Alves); graham (Graham Y. Mostyn); dane (Dane Snow); yves (Jean- 
Yves Michel); ras (Bob Sutherland); tomho (Tom Ho); michael (Chris Michael); tbr (Tim B. 
Robinson) 

Re: Euterpe review minutes, 4/7/95 


John Campbell writes : 
> 

>as Jack Wenstrand was saying 

> . . 

>.. * John Campbell. Resis cell. Connected properly? 

> . . Please check it out and send mail . 


> 


>This cell, resis. ly was edited on july 14, released on aug 6 and causes 
>all ttl io buffers to fail lvs. does someone want to take on the edit 
>of this cell, must be done in context of the chip. 
> 

>my understanding is that the changes were directed by fab so maybe they 
>should direct the fixes so we don 1 1 unsolve what they were trying to 
>f ix. 

> 

>paulp?? maybe. 

the changes were to comply with what was (at that time} the current metal rules. I 
believe the open is simply because the pad metal edits were not completed because of new 
information from the fab which invalidated much of the work done on the pads at that time. 
However, the lower layer edits were required which is why the pads were released. 

No one seems to understand how this cell works and I must have it completed so I can start 
up a fullchip lvs. _If_ I can get an lvs started this morning, it is not going to be 
completed until late Saturday, which is over a day after the second run of the drc 1 s will 
be started. If the lvs comes back bad, and it requires lower layer edits, then we've just 
blown the tapeout schedule . 

All I need is a quick fix to make it lvs correct. The metals are being completely redone, 
and I'm not going to wait for that to be completed before starting the fullchip lvs {to 
verify the lower layers) . 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-810 0 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 


Dave 
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From: efelias (Eldred Felias) 

Sent: Tuesday, August 08, 1 995 1 : 00 AM 

To: stick (Bruce Bateman) 

Cc: geert (Geert Rosseel); bpw (B. P. Wong) 

Subject: ctag Ivs status 


Bruce , 


The ctag lvs is almost clean. There are 16 unmatched schematic devices and I haven't 
had a chance to check them yet. The next two weeks is very critical for getting euterpe 
ready for tape out and I will be helping on doing drc fixes. 
However, if you find where the problem is on ctag, I 1 11 be glad to fix it. 

Thanks, 
Eldred 
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From: efelias (Eldred Felias) 

Sent: Tuesday, August 08, 1 995 1:00 AM 

To: stick (Bruce Bateman) 

Cc: geert (Geert Rosseel); bpw (B. P. Wong) 

Subject: ctag Ivs status 


Bruce , 


The ctag lvs is almost clean. There are 16 unmatched schematic devices and I haven't 
had a chance to check them yet. The next two weeks is very critical for getting euterpe 
ready for tape out and I will be helping on doing drc fixes. 
However, if you find where the problem is on ctag, I'll be glad to fix it. 

Thanks , 
Eldred 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Monday, August 07, 1995 9:50 PM 

zeus 

mouss 

Meeting summary 


Some notes from friday's general meeting. 

Bill had followed up on actions from last week. Taking data from Microprocessor Report he 
concludes that cost per 8" wafer on a modern microprocessor capable process is $4k/wafer. 
Looking at 3 different yield models (seed, murphy, poisson) concludes that 14mm pers side is 
at a knee on the cost curve. Bigger than that gets expensive. His bottomline is given a 
wafer cost and a defect density, we can expect to predict die cost to within 25%. 

Action: bill, tbr to get more recent data for wire statistics on euterpe and mnemo. 

Done, data supplied to bill. 

Bill then showed data on number of wires as a function of die size. 

Combining this with the previous data he could derive cost as a function of number of 
wires. He also had data on memory cell areas but has not yet factored that into the cost 
calculation. 

Action: bill to get ram data into cost calculation. 

Todd showed slides from the second meeting of the marketing sub-group which has been 
considering modem, set top box and PC related platforms. He showed a chart relating human 
factors, applications, platforms and features. Lisar observed that with the relatively 
high power levels of high performance implementations, important application areas may not 
have been getting enough consideration, eg. 

headend equipment. Craig and gmo added studio equipment and network equipment to this 
list. 

Todd said the group was having a hard time identifying the strategic and financial 
objectives of Zeus. He noted that both the CDM and set top box involved large market 
risk. In the PC area he sees a migration to more integration of media functions. He sees 
two ways to a media computers: migration from the PC, or migration from the set top box, 
and says the PC maker have a huge advantage here. 

There was lots of discussion on this point, but I did not record clear conclusions in my 
notes . 

Some approaches to reducing risk were noted: 
Licensing 

Adopting a less product oriented and more market oriented approach 
Adopting a more component oriented strategy 
Become less cable oriented and more PC oriented 

Hedge against slow market development by enabling other applications 

He presented a specific proposal: 

pentium general performance plus great DSP 
Offered as a PC add- in 
Offer higher integration 
Offer new functions 

There was no agreement on this! 

Finally he noted that we do hard/ complicated things without thinking through what we are 
going to do with the results. 
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Action: the group to consider head end, studio and network equipment applications also. 

Craig gave a brief summary of of a presentation he had made on his work on dynamic x86 
translation. 

Some good results looked possible but would rely on architectural features not implemented 
int he Euterpe design. I particular support for unaligned loads and stores. He noted 
that good support for fast branches was essential. 

He showed an example (a memory to memory operation adding to the contents of a register) 
which under interpretation would require 3 3 instructions but which with translation could 
be reduced to 3 . 

Further, on a superstring machine, those three instructions could execute in a single 
cycle . 

On performance measurements, gmo said booting UNIX to a prompt on Euterpe was 21 million 
instructions, which too 70 million major cycles to execute. Allowing for the fact that it 
is only attempting to use 1 cylinder, that one cylinder is less than 3 0% utilized. Of the 
50 million unused cycles the rough breakdown is: 

20M dcache miss ) assumes SDRAM access latency for refil 

13M icache miss ) 

7M issue restrictions (mostly waiting for store slots} 

5M branch penalties (losing 4 cycles per branch) 

Note that this test does not include clearing memory which would be needed in real life 
because the simulator can fake that to shorten run-time. 

It was noted that in the STB application 20% of cycles were unaccounted for. 
Action: gmo, gregg, craig, hayes to get to the bottom of this and report back. 
On specmarks, Euterpe gets between 0,3 and 0.4 instructions/cycle in a single thread. 
Action: group, find data on other applications 

Action: Hayes, look at potential compiler enhancements to address some of these losses. 

I left the meeting at this point. If there was significant further discussion can someone 
post a follow up please? 

Tim 
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From: vanthof (vant) 

Sent: Monday, August 07, 1 995 4:38 PM 

To: hardheads 

Cc: vanthof (Dave Van't Hof) 

Subject: new option to rdrc/qdrc 


I've added a new option to the rdrc and qdrc scripts; -sdec 

This option runs a special drc flow: sdecf iller . vc which runs the tapeout sdec filling 
routine and then reports any drc violations associated with it. 
The types of drc errors that can occur; 

contped over white space 

coincident contped edges with poly at white space edge 
coincident contped edges with sdec at white space edge 
allpoly+sdec rain space 
allpoly+sdec min width 
sdec min spacing 

There will be addition error flags which in reality are the surrounding sdec or contped 
error. The error messages will tell you which. These are areas 5 0 udrs around each error 
flag to give you context of what the synthesized sdec layer really looks like to help 
determine why the error occurred. 

Thanks , 
Dave 

Dave Van't Hof MicroUhity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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Subject: 


Sent: 

To: 

Cc: 


From: 


paulp (Paul Poenisch) 

Monday, August 07, 1995 10:46 AM 

vant 

geert (Geert Rosseel); torn (Tom Laidig); hopper (Mark Hofmann) 
Re: pad metals 


> 


> 


> Hi guys, since the lower layers seem to be done (except for what to do 

> with 20. 85. 30. a errors), I was wondering what the status of the metals is. 

> The reason is I am about to launch a full chip lvs to verify the lower 

> layers are okay (no shorts through poly, etc, etc) . However, if the 

> metals are going to cause shorts, I can't do that and we will need the 

> metals at least shorts free to tapeout the lower layers. Any ideas? 


There may be some shorts in the pad cells due to the changes that were made in the diodes 
there. I'll take a look at it this morning with Orlando, we should be able to elliminate 
the shorts simply by removing all the contact pedestal, but I'm not sure what that would 
do to the LVS. 


> 


> Thanks, 

> Dave 


Paul. 
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From: pauip (Paul Poenisch) 

Sent: Monday, August 07, 1995 10:43 AM 

To: vant 

Cc: geert (Geert Rosseel); orlando (Orlando Hernando); torn (Tom Laidig) 

Subject: Re: pads 


> Orlando Hernando writes: 

> > 

> >Howdee , 

> > 

> >I just finished drc • ing all of the pad cells. There are some error 

> >flags that 

> > 

> >remain: 

> > 

> > floating waffle poly's should go away at the full {including metals) drc. 

> > 

> > flags at the cell edges should go away at the next level. 

> > 

> > error flags in the seal and crack areas that i'm not sure if ok: 

> > 

> > rl5.85.35a min Pact space to polylsi when not on base or burried 

> > contacts 

> > 

> > error flags in the pwrbase r20.85.30a min Nact space to polylsi 

> > when not on 

> > 

> > base or burried contact=0 

> > 

> >Dave, if ya'll can stop by my area monday morning i'd like to have you check them out. 

> > 

> >I've been working in /u/vanthof /compass /mobi/euterpe /pads so i don't 

> >have 

> > 

> >anything checked out. The drc error files (-lower) are also there if 

> >you want to see thera. 

> > 

> >See ya 

> > 

> >oh 
> 

> Thanks Orlando. I may check these in this weekend to get everything 

> ready for tapeout. 
> 

> I am concerned about the drc error in pwrbase, 2 0.8 5. 30. a This is a 

> real error according to the design rules I have. This rule is to 

> prevent us from putting silicide on top of gates. We will have 

> hundreds of thousands of these errors in euterpe unless this is either fixed or we 
change the rule. 

> 

> Paul, can you comment on this? The lower layers were to be frozen at 

> midnight on friday. So either we delay the freezing on this until 

> it's resolved or we let it go. 

> 

> I'm for letting it go {changing the drc flow) unless it will cause a 

> nasty short. Mainly because we need to get this silly chip frozen... 
> 

> Thanks. 

> Dave 
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Sorry I didn't respond to this earlier, I don't have access to e-mail at home. 

I agree with you Dave, we should let this go. I didn't have Orlando do any- thing to poly 

1 silicide because it's now considered one to the "metal" layers. 

As a result when we took the buried contacts out of the crack and seal rings and the 
pwoerbase cell we ended up with poly 1 silicide over gate oxide. When we go back to 
finish the metal layers for these cells we will take care of these erorrs. 

Paul. 
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Sent: 
To: 

Cc: 


Subject: 


From: 


hopper (Mark Hofmann) 
Monday, August 07, 1 995 1 :28 AM 
vant 

orlando (Orlando Hernando); mudge (john mudge); paulp (Paul Poenisch); vanthof (Dave 
Van't Hot); geert (Geert Rosseel) 
Re: pad cells 


vant writes: 
Hi guys, 

I've checked in all the pad cells. I think they are now drc clean for 
the lower layers in the context of euterpe. The next thing to check for 
is to ensure there are no metal shorts so I can run a fullchip lvs. Without 
that, I can't finish the tapeout of the lower layers by the end of the week. 

You will not need to work from my /u/ vanthof/ compass /mobi/ euterpe /pads 
directory anymore. All you need to do is go back to your normal compass 
directory for euterpe as all pad cells are now checked into proteus . 

I have locked all cells down. If you need to work on any cells, please let 
me know and I'll unlock them. 

Thanks, 
Dave 

Thanks for all the work, Dave. 

We will channel requests for unlocking through you. 
-hopper 
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F rom : vanthof (vant) 

Sent: Monday, August 07, 1995 3:09 AM 

To: orlando (Orlando Hernando); mudge Qohn mudge); pautp (Paul Poenisch) 

Cc: vanthof (Dave Van't Hof); geert (Geert Rosseel); hopper (Mark Hofmann) 

Subject: pad cells 


Hi guys, 

I've checked in all the pad cells. I think they are now drc clean for the lower layers 
in the context of euterpe. The next thing to check for is to ensure there are no metal 
shorts so I can run a fullchip lvs . Without that, I can't finish the tapeout of the lower 
layers by the end of the week. 

You will not need to work from my /u/ vanthof /compass /mobi/ euterpe /pads 

directory anymore. All you need to do is go back to your normal compass directory for 
euterpe as all pad cells are now checked into proteus . 

I have locked all cells down. If you need to work on any cells, please let me know and 
I'll unlock them. 

Thanks , 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context." The Tick to Thrackazog 
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From: vanthof (vant) 

Sent: Sunday, August 06, 1 995 1 0:55 PM 

To: john mudge 

Cc: paulp (Paul Poenisch); orlando (Orlando Hernando); hopper (Mark Hofmann); geert (Geert 

Rosseel); torn (Tom Laidig); mudge (John mudge) 
Subject: Re: Returned mail: User unknown (fwd) 


john mudge writes: 
> 

>Each, 

>I thought that the daily meetings were going to grind through the 
>metals on the pads. If we think that that is going to take a long time 
>then we could fake up something on the pad just to get it through the lvs. 
>Are there problems out side of the pads? 
> 

> j ohnnymudge 

We have a route of euterpe that I'm trying to lvs. I r m counting on the new pads to have 
no shorts so I can verify the new, final lower layers of euterpe are lvs clean. running 
lvs using the old pads is not going to tell me much especially since the lower layers have 
changed . 

All I need is metals that are lvs clean. I don't need them drc clean for the lvs run. 

Thanks , 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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From: vanthof (vant) 

Sent: Sunday, August 06, 1995 11:38 AM 

To: paulp (Paul Poenisch); orlando (Orlando Hernando); johnny 

Cc: vanthof (Dave Van't Hof); hopper (Mark Hofmann); geert (Geert Rosseel); torn (Tom Laidig) 

Subject: pad metals 


Hi guys, since the lower layers seem to be done (except for what to do with 20. 85. 30. a 
errors), I was wondering what the status of the metals is. 

The reason is I am about to launch a fullchip lvs to verify the lower layers are okay (no 
shorts through poly, etc, etc) , However, if the metals are going to cause shorts, I can't 
do that and we will need the metals at least shorts free to tapeout the lower layers. Any 
ideas? 

Thanks , 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender 1 I mean, I know it, I'm not dumb. just 
not in this context . " The Tick to Thrackazog 
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Subject: 


Sent: 
To: 

Cc: 


From: 


vanthof (vant) 

Sunday, August 06, 1 995 1 1 : 1 4 AM 

tbr (Tim B. Robinson); hopper (Mark Hofmann); geert (Geert Rosseel); iisar (Lisa Robinson) 
vanthof (Dave Van't Hof); torn (Tom Laidig); wampler (Kurt Wampler) 
fuHchip euterpe Ivs finished. 


The euterpe fullchip lvs finished about 3:10 this morning. Here's the stats: 


NUMBER OF UN- MATCHED SCHEMATICS DEVICES 
NUMBER OF UN -MATCHED LAYOUT DEVICES 
NUMBER OF MATCHED SCHEMATICS DEVICES 
NUMBER OF MATCHED LAYOUT DEVICES 


479 
327 

= 2106630 
= 2106630 


I have not had time to look at it yet. Plus with the drc edits that have been made, I 
believe the next lvs run will be much cleaner (many shorts were found in the drc fixing 
process) . 

I'll try to take a look at it this morning. The results are: 
/u/vanthof /compass /raobi/ euterpe /tapeout/ euterpe. compare/ euterpe . lvs 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context." The Tick to Thrackazog 


Thanks , 
Dave 
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From: vanthof (vant) 

Sent: Saturday, August 05, 1 995 1 1 :49 PM 

To: Orlando Hernando 

Cc: geert (Geert Rosseel); orlando (Orlando Hernando); paulp (Paul Poenisch); vanthof (Dave 

Van't Hof); torn (Tom Laidig) 
Subject: Re: pads 


Orlando Hernando writes: 
> 

>Howdee , 
> 

>I just finished drc ' ing all of the pad cells. There are some error 

>flags that 

> 

> remain: 
> 

> floating waffle poly's should go away at the full (including metals) drc. 
> 

> flags at the cell edges should go away at the next level. 

> 

> error flags in the seal and crack areas that I'm not sure if ok: 
> 

> rl5.85.35a min Pact space to polylsi when not on base or hurried 

> contact=0 
> 

> error flags in the pwrbase r20.85.30a win Nact space to polylsi when 

> not on 

> 

> base or burried contact =0 

>Dave, if ya'll can stop by my area monday morning i'd like to have you check them out. 
> 

>I've been working in /u/vanthof/ compass /mobi/euterpe /pads so i don't 

>have 

> 

>anything checked out. The drc error files (-lower) are also there if 

>you want to see them. 

> 

>See ya 
> 

>oh 

Thanks Orlando. I may check these in this weekend to get everything ready for tapeout. 

I am concerned about the drc error in pwrbase, 20. 85. 30. a This is a real error according 
to the design rules I have. This rule is to prevent us from putting silicide on top of 
gates. We will have hundreds of thousands of these errors in euterpe unless this is 
either fixed or we change the rule. 

Paul, can you comment on this? The lower layers were to be frozen at midnight on friday. 
So either we delay the freezing on this until it's resolved or we let it go. 

I'm for letting it go (changing the drc flow) unless it will cause a nasty short. Mainly 
because we need to get this silly chip frozen. . . 

Thanks . 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context." The Tick to Thrackazog 
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Sent: 
To: 

Cc: 


Subject: 


From: 


vanthof (van!) 

Saturday, August 05, 1995 1:09 PM 
Geert Rosseel 

hopper (Mark Hofmann); lisar (Lisa Robinson); tbr (Tim B. Robinson); torn (Tom Laidig); 
wampler (Kurt Wampler); vanthof (Dave Van't Hot) 
Re: euterpe lower drc status 


Geert Rosseel writes: 


> 


>Orlando is currently working on the pad lower layers. He was going to 

>finish it as fast as possible. 

> 

>Orlando brought up a good point. He is really worried about poly to 
>poly shorts in the pads since we cannot have floating poly and it's 
>hard to figure out what poly is hooked up to what supply without having 
>the metals done . . . 
> 

> Geert 

Well, once he's done, I'll start up an lvs (which includes a shorts check). 

If we find any shorts, I'll kill the lvs part and extract the shorts. The shorts part 

takes 3 days. 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't, know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 


Dave 
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Sent: 

To: 

Cc: 


Subject: 


From: 


hopper (Mark Hofmann) 
Saturday, August 05, 1995 6:03 AM 
Geert Rosseel 

lisar (Lisa Robinson); tbr (Tim B. Robinson); vanthof (Dave Van't Hof); torn (Tom Laidig); 
wampler (Kurt Wampler) 
Re: euterpe lower drc status 


Geert Rosseel writes: 

Orlando is currently working on the pad lower layers. He was going to finish 
it as fast as possible. 

Orlando brought up a good point . He is really worried about poly to poly 
shorts in the pads since we cannot have floating poly and it's hard to 
figure out what poly is hooked up to what supply without having the metals 


Does he need all metals or only metal 1? I think the plan for metal 1 was kind of stable- 
or am I wrong? 


done 


-hopper 
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Sent: 

To: 

Cc: 


Subject: 


From: 


geert (Geert Rosseel) 
Saturday, August 05, 1995 1:01 PM 
hopper; lisar; tbr; vanthof 
torn; warn pier 

Re: euterpe lower drc status 


Orlando is currently working on the pad lower layers. He was going to finish it as fast as 
possible . 

Orlando brought up a good point. He is really worried about poly to poly shorts in the 
pads since we cannot have floating poly and it's hard to figure out what poly is hooked up 
to what supply without having the metals done . . . 


Geert 
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From: William Herndon [bill@microunity.com] 

Sent: Saturday, August 05, 1 995 1 2:40 PM 

To: Tim B. Robinson 

Cc: Bruce Bateman; Craig Hansen; Drew Wingard; Geert Rosseel; Jack Wenstrand; John 

Moussouris; Steve Manser; john mudge 
Subject: Re: aug3 minutes, next meeting aug10 


thx, i will add the numbers to my spread sheet., it might be useful to have the breakdown 
by layer because i am assuming all of layer 2 is available for routing, and it isn't. 

On Fri, 4 Aug 1995, Tim B. Robinson wrote: 


> William Herndon wrote (on Fri Aug 4) : 

> The "old business" action items from the aug 4 meeting were: 

> 1. more data points on wire length etc. from other data bases (i'll get 

> it from tbr) 
> 

> The latest euterpe route has 88458 nets and a total of 49766387 

> microns. I don't have the breakdown of the layers but I should be 

> able to get it if you need it. 
> 

> The mnemo route has 28096 nets and a total of 20741901 microns. 

> 

> Tim 
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From: vanthof (vant) 

Sent: Saturday, August 05, 1 995 1 0:33 AM 

To: Mark Hofmann 

Cc: vanthof@microunity.com; tbr (Tim B. Robinson); lisar (Lisa Robinson); geert (Geert Rosseel); 

torn (Tom Laidig); wampler (Kurt Warn pier) 
Subject: Re: euterpe lower drc's finished. 


Mark Hofmann writes: 

> 

> 

> Thanks , Dave 

>I did a quick grep thru the file [ 

-vanthof /compass /mobi /euterpe/ tapeout/euterpe_lower. err ] abd found: 


> 

2: 9 r56 

b 

Min Polyl feature space = 10 udrs; 

> 

30: 

9 

r56.d: Max Polyl feature space = 10 udrs; 

> 

48: 

9 

r40&45&50&55.80.a: Max Polyl overlap of SDEC = 0 udrs; 

> 

62: 

9 

r80.a: Min SDEC feature size = 10 udrs; 

> 

156: 

9 

r80.b: Min SDEC feature space = 10 udrs; 

> 

206: 

9 

r80.90.a: Min Contact Pedestal overlap of SDEC is 10 udrs; 

> 

3434: 

9 

r80 . 90 . 56 . a&b: Min SDEC space to all ContPed over polyl. (To contped over 

white space 


3udrs) is 2 udrs; 

> 

3606: 

9 

r81.a: Min allpolyl+sdec feature size = 10 udrs; 

> 

3614: 

9 

r81.b: Min allpolyl+sdec feature space = 10 udrs; 

> 

3654 : 

9 

r85.a: Min Polyl Silicide feature size = 10 udrs; 

> 

4690: 

9 

r85.90.a: Min Polyl Silicide space to all Cont Ped is 5 udrs; 

> 

8542 : 

9 

r85.90.56.a: Min Polyl Silicide overlap of Cont Ped & Polyl feature size = 8 


udrs ; 

> 19530: 9 rl0.20.b: Min Nwell space to n+active = 29 udrs ,- 

> 19802: 9 rl5 20. 81. a: All poly OR d sdec must enclose all active by 3 
>udrs ; 

> 20630: 9 rl5.20.10.a: Min P+Act in Nwell to N+Act not in Nwell = 40 
>udrs ; 

> 21094: 9 rl5.40.c: min active ext into polyl for devices < 14 udrs 
>wide = 2 -udrs; 

> 64682: 9 rl5.40.a: Min P+Polyl enclosure of P+Active is 3 udrs; 

> 64690: 9 r20.85.30.a: Min N+ Act space to Polyl Sil when NOT on 
>Buried Cont = 0 udrs; 

> 65318: 9 r4 0.45.a: Min P+Polyl space to N+ Polyl is 10 udrs; 

> 65346: 9 r40&45&50 . 85 . 80 . a : Min polyl end of plsil at non-butting 
^contact edge = 2 udrs ,- 

> 

>This shows most (2/3) of the errors are: 
> 

> rl5.40.c: min active ext into polyl for devices < 14 udrs wide = 2 

> udrs; 
> 

> - hopper 

Yes, I believe that most of the errors will be in areas that Eldred just cleaned up as I 
started the drc on monday and he's been fixing lots of things since then. In fact, the cr 
block is drc/lvs clean. I'm not sure about the ctag. 

I'll load up this file and see where the error are. 

Thanks , 
Dave 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context." The Tick to Thrackazog 
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From: hopper (Mark Hofmann) 

Sent: Saturday, August 05, 1 995 2:57 AM 

To: vant 

Cc: tbr (Tim B. Robinson); lisar (Lisa Robinson); geert (Geert Rosseel); vanthof (Dave Van't Hot); 

torn (Tom Laidig); wampler (Kurt Wampler) 
Subject: Re: euterpe lower drc's finished. 


vant writes : 


It takes 4 days to complete the lower drc ' s I need to see what checks are 
taking so long, but there is very little I can do about it (except run on 
the alpha machine . . . ) 

Okay. I take it, it is the Dracula part of the flow which is limiting things? 

The output file is almost 2 MB in size. Not bad, but bigger than 
I had hoped. 

I have not looked at it yet tonight, but will do so in the morning. 


Later, 
Dave 


Thanks , Dave 

I did a quick grep thru the file [ -vanthof/ compass /mobi /euterpe/tapeout/euterpe_lower . err 
3 abd found: 

2: 9 r56.b: Min Polyl feature space = 10 udrs; 
r56.d: Max Polyl feature space = 10 udrs; 
r40&45&50&55 .80 .a: Max Polyl overlap of SDEC = 0 udrs; 
r80.a: Min SDEC feature size = 10 udrs; 

9 r80.b: Min SDEC feature space = 10 udrs; 

9 r80.90.a: Min Contact Pedestal overlap of SDEC is 10 udrs; 

9 r80 . 90 . 56 .a&b: Min SDEC space to all ContPed over polyl. (To contped over 
= 3udrs) is 2 udrs; 

9 r81.a: Min allpolyl+sdec feature size = 10 udrs; 
9 r81.b: Min allpolyl+sdec feature space = 10 udrs; 
9 r85.a: Min Polyl Silicide feature size = 10 udrs; 


30; 9 
48: 9 
62: 9 
156: 
206: 
3434: 
white space 
3606 
3614 
3654 
4690 
8542 

udrs ; 

19530; 

19802 : 

20S30 : 

21094 : 

64682 : 

64690 : 

65318 : 

65346 : 
udrs ; • 


9 r85.90.a: Min Polyl Silicide space to all Cont Ped is 5 udrs; 

9 r85.90.56.a: Min Polyl Silicide overlap of Cont Ped & Polyl feature size = 8 
9 rl0.20.b: Min Nwell space to n+active = 29 udrs; 

9 rl5 2 0.81. a: All poly OR d sdec must enclose all active by 3 udrs; 
9 rl5.20.10.a: Min P+Act in Nwell to N+Act not in Nwell =40 udrs; 
9 rl5.4 0.c: min active ext into polyl for devices < 14 udrs wide = 2 udrs; 
9 rl5.40.a: Min P+Polyl enclosure of P+Active is 3 udrs; 

9 r20.85.30.a: Min N+ Act space to Polyl Sil when NOT on Buried Cont = 0 udrs; 
9 r40.45.a: Min P+Polyl space to N+Polyl is 10 udrs; 

9 r4 0&4 5&50.85.80.a: Min polyl encl of plsil at non-butting contact edge = 2 


This shows most (2/3) of the errors are: 


rl5.4 0.c: min active ext into polyl for devices < 14 udrs wide = 2 udrs; 
-hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@gaea.microunity.com] 
Friday, August 04, 1995 11:52 PM 
William Herndon 

Bruce Bateman; Craig Hansen; Drew Wingard; Geert Rosseel; Jack Wenstrand; John 
Moussouris; Steve Manser; john mudge; zeus technology committee - William Herndon 
aug3 minutes, next meeting aug10 


William Herndon wrote (on Pri Aug 4) : 

The "old business" action items from the aug 4 meeting were: 

1. more data points on wire length etc. from other data bases (i'll get 

it from tbr) 

The latest euterpe route has 88458 nets and a total of 49766387 microns. I don't have the 
breakdown of the layers but I should be able to get it if you need it , 

The mnemo route has 28096 nets and a total of 20741901 microns. 


Tim 
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From: pmayer (Patricia Mayer) 

Sent: Friday, August 04, 1 995 1 :04 AM 

To: tbr 

Cc: pmayer 

Subject: Re: Bad board news 


> From tbr Thu Aug 3 18:46:47 1995 

> To: pmayer (Patricia Mayer) 

> Subject: Re: Bad board news 


> Patricia Mayer wrote (on Thu Aug 3) : 
> 

> However, because of the tab, 7 mil pads spaced at 11.8, the pin to 

> pin rule is 4.8, line to pin is 5.3 and line to line is 5.8. The TAB 

> area is 

> the exception to the rule but DRC's are global across the board in Allegro. 

> If, however, a 6 mil grid is used, the rest is easy (easier said!). 

> I don't have any understanding why the grid wasn't utilized and respected. 
> 

> But even if you use a 6mil grid, do you not still have the problem 

> that you have to violate that in the region of the pads? 


No because the line to line is rule is 5.8 just for that reason. Allegro allows for 
snapping our of the off grid pad and to a 6 mil grid (Thats the beauty of the grid. ) I had 
to draw this for myself, perhaps we could meet sometime tomorrow for a short meeting. 


> > 

> > Anyway, after I reset the rules there were 171 errors! Of course 

> > the design 

> > summary we reviewed during our meetings was based on the erroneous 

> > setting so 

> > it looked great . 

> > 

> > How big a deal is it to edit these to correct them? 
> 

> I'd estimate at least a two weeks per board (except Herminatior) . After 

> the 

> traces and via locations are fixed, the inner layer shapes need to be 

> re- generated (drc was also set to 5) along with the drill and supporting 

> documents . 
> 

> That sounds like a lot. 

Yes, but with the way its sorted out, I think it can be two weeks total. 


> > This also effects the Euterpe XRAM which might be easier to re-do 

> > once the 

> > Euterpe module is fixed. 

> > 

> > The Mnerao module had 229 errors. This will need editing for the 

> > new pinout 

> > anyway. 

> > 

> > Are they mostly in the DRAM area, or on the hermes channel? 
> 

> I'm seeing about 100 of the errors are around the DRAMs where we do have 
5/5 
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> routing between the surface mount pads . 
> 

> Was the 5/5 explicitly intended in those areas or did it just creep 

> through because of the incorrect DRC? 

Intended/ we have 15 mils space between these pads and just like on Hestia it makes sence 
to hook these up on the same side and the pads in order to avoid many many vias . 

> The rest is random expecially in 

> areas densly populated with 4 5 degree lines. These areas, of course, have a 

> lower spacing then the parallel lines. 
> 

> > 

> > And the Herminator has 24 errors. These are just spacing for the 

> > vias to 

> > provide inner layer, gnd and vdde, coverage between the vias. 

> > 

> > Does this mean we get close to slots again? 

> 

> Yes, and that wasn't caught at a review either. I don't think its a big 

> deal 

> on the herminator but I don't see why we shouldn't fix it. 
> 

> > 

> > I'm sure all of this is fix- able. 

> > 

> Great. Jay did stop by and mentioned he had a ring pinout and he would 

> start 

> working on the schematics since Ngau is out and I'm working on the Euterpe 

> bare die test board (MMS membrane on the round card) . I would think thats 

> the next highest priority in line and I thought I'd make time to reroute 

> the Pandora Euterpe. 
> 

> Yes, Cronus and Euterpe have to take priority over mnemo and the 

> bridge 


Thank you for identifying the priority. 


> I created a macro but that still requires the layout designers remember to 

> 'run' the damn thing. (I'm resisting "having an attitude" on this but I'm 

> very disappointed and on occasion can't help myself.) 
> 

> Sometimes people resist automation because they see it at first as an 

> intrusion on their control of their own work. You have to sell it as 

> a tool which improves productivity and quality so the result of their 

> work is more highly valued. 

Yes I understand. Thank you for the attatude adjustment, I'm already regaining my sence of 
humor . 


> > 

> > 

> > I think in view of things said at the meeting today this would be just 

> > the right time to raise that. 

> 

> Howard seemed to think "extra hours" would be ok. it seems as though he 

> sees 

> the re-pinout as the problem.? 
> 

> Sorry I'm out of context. You mean the change to the mnemo/dram interface? 

Right, sorry for throwing you off. I ment the repinout on mnemo was seen as a problem. 
Howard is a good guy, I need to keep up the sell and remind him and myself that he/we 
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is/are valued. I think I'll move him to Euterpe while I finish up the guidelines. 


> > 

> > Given this surprise I'm wondering how fine we should cut things in 

> > getting first versions of the boards fabed. We have fairly 

> > conservative numbers in the schedule for fab and assembly, but given 

> > the possibility of something of this seriousness not being picked up 

> > till Hadco are looking at the artwork (and I guess based on past 

> > experience there has always been some issue) , we may want to look at 

> > sending them out earlier. 
> 

> I really think this is a GREAT idea. I'll work with Philip to prepare an 

> evaluation package for manufacturing as soon as we are done. An evaluation 

> may even be free J? 

> 

> OK thanks. 

> 

> > 

> > Tim 


> I'll update the schedule and have that out by the end of the day. 

> I suppose I need to take this to the Pandora meeting. 
> 

> Yes, but the best thing would be to try and get lisar to integrate it 

> with the big schedule. 

OK I've already mailed her on this. 


Tim 


-Pattie 
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Sent: 
To: 

Cc: 


From: 


pmayer (Patricia Mayer) 
Friday, August 04, 1995 12:48 AM 


howard; ngau 
tbr; pmayer 


Subject: 


PCB priorities 


In light of the new priorities set at the Comms meeting, we have new priorities! 


Tim B. Robinson wrote (on Thu Aug 3) : 

>Cronus and Euterpe have to take priority over mnemo and the bridge. 
> Well, not explicitly mentioned, but the backplane and ISA cards are 
>just as essential as Cronus and Euterpe for the system bring up. 

Howard, will you please take the Pandora -Euterpe module first? Keep up the good work on 
the Euterpe test boards too! Then on to Mnemo. 

Ngau, please continue the ISA first (since its pretty well defined) , then continue the 
Backplane. Then on to the Bridge. 

I'll continue the Euterpe Round card and Cronus. 

Of course things may need to be moved around so I appreciate your flexability. 


Thanks 
-Pattie 
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Subject: 


Sent: 

To: 

Cc: 


From: 


for 

Thursday, August 03, 1995 8:47 PM 
pmayer (Patricia Mayer) 
pmayer 

Re: Bad board news 


Patricia Mayer wrote (on Thu Aug 3) : 

Ah, I do remember that Brian had requested Bill review something using 
these numbers and because 6/6 was the rule for these lines it became the 
standard. However, because of the tab, 7 mil pads spaced at 11.8, the pin to 
pin rule is 4.8, line to pin is 5.3 and line to line is 5.8. The TAB area is 
the exception to the rule but DRC's are global across the board in Allegro. 
If, however, a 6 mil grid is used, the rest is easy (easier said!) . 
I don't have any understanding why the grid wasn't utilized and respected. 

But even if you use a 6mil grid, do you not still have the problem that you have to 
violate that in the region of the pads? 


> Anyway, after I reset the rules there were 171 errors! Of course the design 

> summary we reviewed during our meetings was based on the erroneous setting so 

> it looked great. 
> 

> How big a deal is it to edit these to correct them? 

I'd estimate at least a two weeks per board (except Herminatior) . After the 
traces and via locations are fixed, the inner layer shapes need to be 
re- generated (drc was also set to 5) along with the drill and supporting 
documents . 

That sounds like a lot. 


> This also effects the Euterpe XRAM which might be easier to re-do once the 

> Euterpe module is fixed. 
> 

> The Mnemo module had 229 errors. This will need editing for the new pinout 

> anyway . 
> 

> Are they mostly in the DRAM area, or on the hermes channel? 

I'm seeing about 100 of the errors are around the DRAMs where we do have 5/5 
routing between the surface mount pads. The rest is random expecially in 
areas densly populated with 45 degree lines. These areas, of course, have a 
lower spacing then the parallel lines . 

Was the 5/5 explicitly intended in those areas or did it just creep through because of the 
incorrect DRC? 


> And the Herminator has 24 errors. These are just spacing for the vias to 

> provide inner layer, gnd and vdde, coverage between the vias. 
> 

> Does this mean we get close to slots again? 

Yes, and that wasn't caught at a review either. I don't think its a big deal 
on the herminator but I don't see why we shouldn't fix it. 


> I'm sure all of this is fix-able. 
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> Can you assess the effort required so we can decide priorities? Based 

> on today's meeting it's clear we have to have Euterpe and Cronus as 

> the top priorities, though I think our current scheduling says we have 

> these in time even with the other things going on. Jay is going to 

> shift focus from the bridge to Cronus for a while. 

Great. Jay did stop by and mentioned he had a ring pinout and he would start 
working on the schematics since Ngau is out and I'm working on the Euterpe 
bare die test board (MMS membrane on the round card) . I would think thats 
the next highest priority in line and I thought I'd make time to reroute 
the Pandora Euterpe . 

Yes, Cronus and Euterpe have to take priority over mnemo and the bridge 

Howard is working on the Euterpe Yamaichi socket for testing the TAB device 
and Mnemo. I need to verify the constraints are in place for the boards. 
Ngau has the ISA, Backplane and Bridge. Perhaps when she gets back, she 
can pick up on the Euterpe and definitly the Euterpe XRAM. 

Well, not explicitly mentioned/ but the backplane and ISA cards are just as essential as 
Cronus and Euterpe for the system bring up. 


> In the long term, I have already added a copy of the DRC Constraint form to 

> the guidelines. As a matter of fact, thats what I was testing when I discovered 
this. I've also added a requirment to print the DRC constraint settings for 

> the design reviews along with the Summary report currently brought to the 

> review . 
> 

> That ' s a good idea . How are the DRC 1 s run and how is the ruleset 

> selected? Is there any way to automate this (eg with Makefiles) so 

> we can guarantee to get the standard flows from a shared place? 

The ruleset is selected based on the smallest rules and they are on-line 
updates. The designer is responsible for turning the graphics on and there 
is an 'update DRC command to verify the current statistics. 
For areas like the DRAM, I was planning a "before" where the DRC's are set 
to 5.8/6 and then "after" where the DRC's are set to 5/6. This will give us 
an accurate understanding of the DRAM area and DRC's waivable. This actually 
might have been why the DRC's were set to 5 spacing but combined with the 
inaccurate grid setting of 1 mil, its fatal. 

Good automation suggestion (must be why your the boss making the big bucks) . 
I created a macro but that still requires the layout designers remember to 
•run' the damn thing. (I'm resisting "having an attitude" on this but I'm 
very disappointed and on occasion can't help myself,) 

Sometimes people resist automation because they see it at first as an intrusion on their 
control of their own work. You have to sell it as a tool which improves productivity and 
quality so the result of their work is more highly valued. 


> In the short term, I need to ask Howard to put in more hours. He's been really 

> good at putting in his 40 (hourly minded) but I need to reitterate your offer 

> statement that this is a salery position at a startup. We expect the hours. 
> 

> I think in view of things said at the meeting today this would be just 

> the right time to raise that. 

Howard seemed to think "extra hours" would be OK. It seems as though he sees 
the re-pinout as the problem.? 

Sorry I'm out of context. You mean the change to the mnemo/dram interface? 


> I'm really sorry about this, and I'm glad I caught it now. Also in the future 

> I will be reviewing the data on-line to mark the check list. 


Exhibit C17 


Page 132 of 


> Better now than later. Again if there is any opportunity to automate 

> to remove manual steps that could be subject to error let 1 s look at it. 
> 

> Do you have any further thoughts or suggestions? 
> 

> Given this surprise I'm wondering how fine we should cut things in 

> getting first versions of the boards fabed. We have fairly 

> conservative numbers in the schedule for fab and assembly, but given 

> the possibility of something of this seriousness not being picked up 

> till Hadco are looking at the artwork (and I guess based on past 

> experience there has always been some issue) , we may want to look at 

> sending them out earlier. 

I really think this is a GREAT idea. I'll work with Philip to prepair an 
evaluation package for manufacturing as soon as we are done. An evaluation 
may even be free ! ? 

OK thanks. 


I'll update the schedule and have that out by the end of the day. 
I suppose I need to take this to the Pandora meeting. 

Yes, but the best thing would be to try and get lisar to integrate it with the big 
schedule . 

Tim 
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From: pmayer (Patricia Mayer) 

Sent: Thursday, August 03, 1 995 4:51 PM 

To: tbr 

Cc: pmayer 

Subject: Re: Bad board news 


> From tbr Wed Aug 2 23:59:42 1995 

> To: pmayer (Patricia Mayer) 

> Subject: Bad board news 


> Patricia Mayer wrote (on Wed Aug 2) : 
> 

> Tim, 
> 

> I'm sorry to say that I have discovered incorrect DRC settings on several 

> boards . 
> 

> I've been working on the Allegro Design Guidelines for the past week, recording 

> all I've learned about schematics and responding to question Ngau has had that 

> weren't answered in the Guidelines. 
> 

> Great you are adding that stuff . 

My plan is to have this complete by Monday when Ngau returns. Then I'll have a meeting 
with the layout designers and review it all. I'll copy you on the mail. 


> I decided to test my DRC constraints on an "approved 1 ' board. I chose Euterpe. 

> Much to my dismay, the DRC's were set to 5 mil spacing and the layout grid was 

> set to 1 mil. This is a formula for errors! Our design rule is 6/6 and absolute 

> minimum is 5/5. As we know its not nice to push manufacturing. I don't know 

> how the circuit will react to 6/5. .. The rule was set by Bill Herndon who 

> emulated 6/6 (I think?) and I'm not sure if this was only for the diferential 

> pairs only. 
> 

> 6 6 I think pretty much came form the 11.8 mil spacing of the pad 

> ring. The 100 ohm requirement was then satisfied by specifying the 

> dielectric thickness I think. I think bill was mainly looking at the 

> differential pairs because on the digital boards these are really the 

> only things that need controlled impedance. 

Ah, I do remember that Brian had requested Bill review something using these numbers and 
because 6/6 was the rule for these lines it became the standard. However, because of the 
tab, 7 mil pads spaced at 11.8, the pin to pin rule is 4.8, line to pin is 5.3 and line to 
line is 5.8. The TAB area is the exception to the rule but DRC's are global across the 
board in Allegro . 

If, however, a 6 mil grid is used, the rest is easy (easier said!). 

I don't have any understanding why the grid wasn't utilized and respected. 


> Anyway, after I reset the rules there were 171 errors 1 Of course the design 

> summary we reviewed during our meetings was based on the erroneous setting so 

> it looked great, 
> 

> How big a deal is it to edit these to correct them? 

I'd estimate at least a two weeks per board (except Herrainatior) . After the traces and via 
locations are fixed, the inner layer shapes need to be re -generated (drc was also set to 
5) along with the drill and supporting documents. 
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> This also effects the Euterpe XRAM which might be easier to re-do once the 

> Euterpe module is fixed. 
> 

> The Mnemo module had 229 errors. This will need editing for the new pinout 

> anyway . 
> 

> Are they mostly in the DRAM area, or on the hermes channel? 

I'm seeing about 100 of the errors are around the DRAMs where we do have 5/5 
routing between the surface mount pads. The rest is random expecially in 
areas densly populated with 45 degree lines. These areas, of course, have a 
lower spacing then the parallel lines. 


> And the Herminator has 24 errors. These are just spacing for the vias to 

> provide inner layer, gnd and vdde, coverage between the vias, 
> 

> Does this mean we get close to slots again? 

Yes, and that wasn't caught at a review either. I don't think its a big deal 
on the herminator but I don't see why we shouldn't fix it. 


> I'm sure all of this is fix-able. 
> 

> Can you assess the effort required so we can decide priorities? Based 

> on today's meeting it's clear we have to have Euterpe and Cronus as 

> the top priorities, though I think our current scheduling says we have 

> these in time even with the other things going on. Jay is going to 

> shift focus from the bridge to Cronus for a while. 

Great. Jay did stop by and mentioned he had a ring pinout and he would start 
working on the schematics since Ngau is out and I'm working on the Euterpe 
bare die test board (MMS membrane on the round card) . I would think thats 
the next highest priority in line and I thought I'd make time to reroute 
the Pandora Euterpe. 

Howard is working on the Euterpe Yamaichi socket for testing the TAB device 
and Mnemo. I need to verify the constraints are in place for the boards. 
Ngau has the ISA, Backplane and Bridge. Perhaps when she gets back, she 
can pick up on the Euterpe and definitly the Euterpe XRAM. 


> In the long term, I have already added a copy of the DRC Constraint form to 

> the guidelines. As a matter of fact, thats what I was testing when I discovered this. 
I've also added a requirment to print the DRC constraint settings for 

> the design reviews along with the Summary report currently brought to the 

> review. 
> 

> That's a good idea. How are the DRC's run and how is the ruleset 

> selected? Is there any way to automate this (eg with Makefiles) so 

> we can guarantee to get the standard flows from a shared place? 

The ruleset is selected based on the smallest rules and they are on-line 
updates. The designer is responsible for turning the graphics on and there 
is an 'update DRC 1 command to verify the current statistics. 
For areas like the DRAM, I was planning a "before" where the DRC's are set 
to 5.8/6 and then "after" where the DRC's are set to 5/6. This will give us 
an accurate understanding of the DRAM area and DRC's waivable. This actually 
might have been why the DRC's were set to 5 spacing but combined with the 
inaccurate grid setting of 1 mil, its fatal. 

Good automation suggestion (must be why your the boss making the big bucks) . 
I created a macro but that still requires the layout designers remember to 
'run' the damn thing. (I'm resisting "having an attitude" on this but I'm 
very disappointed and on occasion can't help myself.) 


In the short term, I need to ask Howard to put in more hours. He's been really 
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> good at putting in his 40 (hourly minded) but I need to reitterate your offer 

> statement that this is a salery position at a startup. We expect the hours. 
> 

> I think in view of things said at the meeting today this would be just 

> the right time to raise that. 

Howard seemed to think "extra hours" would be OK. It seems as though he sees 
the re-pinout as the problem.? 


> I'm really sorry about this, and I'm glad I caught it now. Also in the future 

> I will be reviewing the data on-line to mark the check list. 
> 

> Better now than later. Again if there is any opportunity to automate 

> to remove manual steps that could be subject to error let's look at it. 
> 

> Do you have any further thoughts or suggestions? 
> 

> Given this surprise I'm wondering how fine we should cut things in 

> getting first versions of the boards fabed. We have fairly 

> conservative numbers in the schedule for fab and assembly, but given 

> the possibility of something of this seriousness not being picked up 

> till Hadco are looking at the artwork (and I guess based on past 

> experience there has always been some issue) , we may want to look at 

> sending them out earlier. 

I really think this is a GREAT idea. I'll work with Philip to prepair an 
evaluation package for manufacturing as soon as we are done. An evaluation 
may even be free ! ? 


> Tim 


I'll update the schedule and have that out by the end of the day. 
I suppose I need to take this to the Pandora meeting. 

Thanks Tim, 
Pattie 
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From: jack (Jack Wenstrand) 

Sent: Thursday, August 03, 1995 1 :34 PM 

To: al; geert; paulp; hopper; vanthof; torn; anh; jack; rich; ong 

Cc: mouss; tony; manser; wingard; mudge; cadettes; fung; kuman tomb; yao; rip; to; ted; ky; liang; 

hoov; trancy; linden; anderson; alves; graham; dane; yves; ras; tomho; michael; solo; tbr; tony 
Subject: Notes, layout review, 8/4/95 


Euterpe pad 

Issues : 

1) SDEC fill is a show stopper. The fab is concerned 
that unless substantial progress is made with 
increasing the amount of SDEC on the die, we will be 
unable to yield anything. In particular, this 
causes emitter-base shorts. The design community is 
concerned that to fully implement the increase in 
SDEC would require a major change in methodology and 
months to implement. 

* Action: Al will see Dave V. to identify the best 
course of action consistent with the Euterpe goal, 
and present an update at the 8/4 layout review. 

2) Pad metal . 

Use long parallel lines. Ml should run 
perpendicular to SDEC . 

3) Pad capacitance. 

Put the pad over a reverse-biased n-well to reduce 
pad capacitance. Turn off the buried layer 
requirement here to prevent autodoping. 

* Action: Geert to make this happen, and coordinate 

with Paul. 

4 ) Protection diode . 

Change metal to distribute current over diode. 
Center contact pedestal over SDEC. Ballast 
resistors might be necessary. 

* Action: Johnny: Work on this, check with Al, feed 

results back to Paul for integration. 

5) Comb structure. 

* Action: Paul: kill it. 

Wait list: 

6) The power bus is too small. 

7) Long contact pedestals occur throughout Euterpe and 
may not makable. 


Next meeting: Today, Thursday, 3pm, Multimedia Room. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr 

Thursday, August 03, 1995 2:00 AM 
pmayer (Patricia Mayer) 
pmayer 

Bad board news 


Patricia Mayer wrote (on Wed Aug 2) : 


Tim, 


I'm sorry to say that I have discovered incorrect DRC settings on several 
boards . 

I've been working on the Allegro Design Guidelines for the past week, recording 
all I've learned about schematics and responding to question Ngau has had that 
weren't answered in the Guidelines. 

Great you are adding that stuff . 

I decided to test my DRC constraints on an "approved" board. I chose Euterpe. 
Much to my dismay, the DRC 1 s were set to 5 mil spacing and the layout grid was 
set to 1 mil. This is a formula for errors! Our design rule is 6/6 and absolute 
minimum is 5/5. As we know its not nice to push manufacturing. I don't know 
how the circuit will react to 6/5.. . The rule was set by Bill Herndon who 
emulated 6/6 (I think?) and I'm not sure if this was only for the diferential 
pairs only. 

6 6 1 think pretty much came form the 11.8 mil spacing of the pad ring. The 100 ohm 
requirement was then satisfied by specifying the dielectric thickness I think. I think 
bill was mainly looking at the differential pairs because on the digital boards these are 
really the only things that need controlled impedance. 

Anyway, after I reset the rules there were 171 errors! Of course the design 
summary we reviewed during our meetings was based on the erroneous setting so 
it looked great. 

How big a deal is it to edit these to correct them? 

This also effects the Euterpe XRAM which might be easier to re-do once the 
Euterpe module is fixed. 

The Mnemo module had 229 errors. This will need editing for the new pinout 
anyway . 

Are they mostly in the DRAM area, or on the hermes channel? 

And the Herminator has 24 errors. These are just spacing for the vias to 
provide inner layer, gnd and vdde, coverage between the vias. 

Does this mean we get close to slots again? 

I'm sure all of this is fix-able. 

Can you assess the effort required so we can decide priorities? Based on today's meeting 
it's clear we have to have Euterpe and Cronus as the top priorities, though I think our 
current scheduling says we have these in time even with the other things going on. Jay is 
going to shift focus from the bridge to Cronus for a while. 

In the long term, I have already added a copy of the DRC Constraint form to 
the guidelines. As a matter of fact, thats what I was testing when I discovered this. 
I've also added a requirment to print the DRC constraint settings for 
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the design reviews along with the Summary report currently brought to the 
review. 

That's a good idea. How are the DRC's run and how is the ruleset selected? Is there any 
way to automate this {eg with Makefiles) so we can guarantee to get the standard flows 
from a shared place? 

In the short term, I need to ask Howard to put in more hours. He's been really 
good at putting in his 40 {hourly minded) but I need to reitterate your offer 
statement that this is a salery position at a startup. We expect the hours. 

I think in view of things said at the meeting today this would be just the right time to 
raise that. 

I'm really sorry about this, and I'm glad I caught it now. Also in the future 
I will be reviewing the data on-line to mark the check list. 

Better now than later. Again if there is any opportunity to automate to remove manual 
steps that could be subject to error let's look at it. 

Do you have any further thoughts or suggestions? 

Given this surprise I'm wondering how fine we should cut things in getting first versions 
of the boards fabbed. We have fairly conservative numbers in the schedule for fab and 
assembly, but given the possibility of something of this seriousness not being picked up 
till Hadco are looking at the artwork (and I guess based on past experience there has 
always been some issue), we may want to look at sending them out earlier. 

Tim 
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From: pmayer (Patricia Mayer) 

Sent: Thursday, August 03, 1995 1:44 AM 

To: tbr 

Cc: pmayer 

Subject: Bad board news 


Tim, 

I'm sorry to say that I have discovered incorrect DRC settings on several boards. 

I've been working on the Allegro Design Guidelines for the past week, recording all I've 
learned about schematics and responding to question Ngau has had that weren't answered in 
the Guidelines. 

I decided to test my DRC constraints on an "approved" board. I chose Euterpe. 
Much to my dismay, the DRC's were set to 5 mil spacing and the layout grid was set to 1 
mil. This is a formula for errors 1 Our design rule is 6/6 and absolute minimum is 5/5. As 
we know its not nice to push manufacturing. I don't know how the circuit will react to 
6/5... The rule was set by Bill Herndon who emulated 6/6 (I think?) and I'm not sure if 
this was only for the diferential pairs only. 

Anyway, after I reset the rules there were 171 errors! Of course the design summary we 
reviewed during our meetings was based on the erroneous setting so it looked great. 

This also effects the Euterpe XRAM which might be easier to re-do once the Euterpe module 
is fixed. 

The Mnemo module had 229 errors. This will need editing for the new pinout anyway. 

And the Herminator has 24 errors. These are just spacing for the vias to provide inner 
layer, gnd and vdde, coverage between the vias. 

I'm sure all of this is fix-able. 

In the long term, I have already added a copy of the DRC Constraint form to the 
guidelines. As a matter of fact, thats what I was testing when I discovered this. I've 
also added a reguirment to print the DRC constraint settings for the design reviews along 
with the Summary report currently brought to the review. 

In the short term, I need to ask Howard to put in more hours. He r s been really good at 
putting in his 4 0 {hourly minded) but I need to reitterate your offer statement that this 
is a salery position at a startup. We expect the hours. 

I'm really sorry about this, and I'm glad I caught it now. Also in the future I will be 
reviewing the data on-line to mark the check list. 

Do you have any further thoughts or suggestions? 
-Pattie 
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Sent: 

To: 

Cc: 


Subject: 


From: 


vanthof (vant) 

Wednesday, August 02, 1995 4:12 PM 

geert (Geert Rosseel); for (Tim B. Robinson); lisar (Lisa Robinson); hopper (Mark Hofmann) 
vanthof (Dave Van't Hof); torn (Tom Laidig) 
fullchip drc run still going 


I have severely underestimated the time it takes to do a fullchip drc run. 
This is the first time a fullchip has been run with the new drc flow which does a 
significant amount of post processing to emulate tapeout. This process added quite a bit 
of time, more than I thought. I had estimated that a lower fullchip drc would take 2 
days , and it ' s probably closer to 

4 or 5 days, I'm unsure of just how long it really will be. 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context." The Tick to Thrackazog 


Dave 
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From: tbr 

Sent: Tuesday, August 01,1 995 8:32 PM 

To: Daniel Albers 

Cc: albers@microunity.com; geert@microunity.com; hopper@microunity.com; 

tau@microunity.com; tom@microunity.com; vanthof@microunity.com; 

wampler@microunity.com 
Subject: Re: euterpe tapout? here we go... 


Daniel Albers wrote (on Tue Aug 1) : 


Let's break the idea of the frame up into 2 parts: 


1) Frame scribeline data 


The frame can always be re -used provided we don't want to change any 
cells inside of it. We did plan on using different etest cells in 
the pollux and euterpe reticle sets. 


2) Device/scribe interface (1 um ring surrounding each device 
placed in the frame) . 

The device/ scribe interface ring will almost always need to be 
regenerated unless we are positive that the die -edge is 
identical between tapeouts. 

On pollux the cell f 0011_ring.ly would just be regenerated and 
checked- in. This takes a couple of hours pollux. Probably the 
same for euterpe. 

Thanks for the clarification. 

Tim 


Daniel Albers albers@microunity.com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 


"Evil is just plain badl You don't cotton to it. You gotta smack it in the 
nose with the rolled-up newspaper of goodness! Bad dog! Bad dogl" 


- The Tick. 
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From: Daniel Albers [albers@microurtity.com] 

Sent: Tuesday, August 0 1 , 1 995 4:35 PM 

To: Tim B. Robinson 

Cc: albers@microunity.com; geert@microunity.com; hopper@microunity.com; 

tau@microunity.com; tom@microunity.com; vanthof@microunity.com; 

wampler@microunity.com 
Subject: Re: euterpe tapout? here we go... 

> the words of Tim 6 . Robinson: 
> 

> 

> Daniel Albers wrote (on Tue Aug 1) : 

> 

> Primarily we put in different etest cells in the frame. 
> 

> So if really pressed could we re -use a frame for a different tapeout? 


Let 1 s break the idea of the frame up into 2 parts : 

1) Frame scribeline data 

The frame can always be re-used provided we don ] t want to change any 
cells inside of it. We did plan on using different etest cells in 
the pollux and euterpe reticle sets. 

2) Device/ scribe interface {1 um ring surrounding each device 
placed in the frame} . 

The device/scribe interface ring will almost always need to be 
regenerated unless we are positive that the die- edge is 
identical between tapeout s . 

On pollux the cell f 0011_ring. ly would just be regenerated and 
checked- in. This takes a couple of hours pollux. Probably the 
same for euterpe. 


Dan 


Daniel Albers albers@microunity.com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 


" Evil is just plain bad! You don't cotton to it. You gotta smack it in the 
nose with the rolled-up newspaper of goodness! Bad dog! Bad dog!" 

- The Tick. 
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From: 
Sent: 
To: 

Cc: 

Subject: 

Daniel Albers wrote (on Tue Aug 1) : 

Primarily we put in different etest cells in the frame. 
So if really pressed could we re-use a frame for a different tapeout? 
Tim 


tbr 

Tuesday, August 01, 1995 2:22 PM 
Daniel Albers 

albers@rnicrounity.com; geert@microunity.com; hopper@microunity.com; 
tau@microunity.com; tom@microunity.com; vanthof@microunity.com; 
wampler@microunity.com 
Re: euterpe tapout? here we go... 
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Subject: 


Sent: 

To: 

Cc: 


From: 


torn (Tom Laidig [tauj) 

Tuesday, August 01, 1995 1 1:02 AM 

Kurt Wampler 

albers (Daniel Albers); geert (Geert Rosseel); hopper (Mark Hofmann); tbr (Tim Robinson); 

vanthof (Dave Van't Hot); tau 

Re: euterpe tapout? here we go... 


Kurt Wampler writes: 
Tom writes : 


>I just got buttonholed by Jack, Al, and Ann for an impromptu meeting 
>about euterpe tapeout, given the edict that we must have euterpe 
>silicon by Dec 31. I explained that euterpe, as it exists now, does 
>not meet the "compromise 1 design rule set developed last week, and I 
>estimated 3 months of layout work before it could be made to do so. 

Not to mention the very real risk that Euterpe would no longer route 
to completion with the compromise rules' larger vias . 

Yah, I mentioned that as well. Also the fact that we'd lose some rows of atoms and a few 
other things by trying to meet the other provisions of the compromise rules. 


>Given this, Al and Ann agreed that the best move is to tape out the 
>baseplate layers (currently defined as 010-140 -- all but metals, 
>SDEC, and silicide) ASAP in their current form, and pressed me for an 
>estimate of how soon this could happen. I made the possibly rash 
> statement that I thought we might be able to tapeout the baseplate on 
>Aug 14. (Jack mentioned some 1- or 2-udr well-well and well-nactive 
>spacing violations, to which Al said "waive them 1 ) 

Will there be any changes needed on the poly layer to comply with 
the new SDEC ISO rules? 

No; we are not going to meet the new SDEC ISO rules. We can dink with SDEC as much as 
seems good to improve our situation vis-a-vis the SDEC ISO rules, but we don't really have 
any time to do this, so I don't anticipate any real progress. 


>After some argument, we settled on Sep 1 as the target date to tape 
>out the layers up through Ml (plus any more metals we can get out by 
>then) , with the remaining metal layers taping out promptly thereafter. 

This is "ship physical tapes on Sep 1" or "commence fracture on Sep 1"? 

I don't see a problem with shipping tapes on Sep 1 as long as we 
start the fracture by Aug. 28. We'll need 2-3 days to compute layers 
010-140, and a little time to review post-fracture DRC flags & write 
the tapes. 

The quoted dates are actual tape ship dates -- ie, we must ship the tapes for 010-140 by 
6pm on Aug 14; 150-180 by 6pm on Sep 1. It sounds as if this means we start the 010-140 
fracture on Aug 11 at the latest . 

The other metals are of less immediate interest to the fab (they need 

Ml to get transistor characterization, which is why that date is spec'ed), but the 

implicit assumption is that we'll ship the other metals within a week or thereabouts. 
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From: Daniel Albers [a!bers@microunity.com] 

Sent: Tuesday, August 01, 1995 10:27 AM 

To: Tim B. Robinson 

Cc: albers@microunity.com; geert@microunity.com; hopper@microunity.com; 

tau@microunity.com; tom@microunity.com; vanthof@microunity.com; 

wampler@microunity.com 
Subject: Re: euterpe tapout? here we go... 


> the words of Tim B. Robinson: 


> Daniel Albers wrote (on Mon Jul 31) : 
> 

> > the words of Tom Laidig [tau] : 

> > 

> > [snip] 

> > 

> > I hope I didn't commit (however tentatively I tried to do so) to 

> > anything _too_ rash. My estimates were predicated on a lot of stuff I 

> > don't know enough about, including, but surely not limited to; 

> > 

> > There's a frame that is ready, or very nearly so 

> > 

> > [snippitte, snip, snip] 

> > 
> 

> The frame is "nearly" ready. The one that is check' d in is completely 

> wrong. But I believe I can have a good frame put together by the guestimated 

> tapeout dates. , . 
> 

> Why does the frame need to be any different from the one (I assume) we 

> have ready for pollux? 


Primarily we put in different etest cells in the frame. 
Dan 


Daniel Albers albers@microunity.com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 

"Evil is just plain bad! You don't cotton to it. You gotta smack it in the 
nose with the rolled-up newspaper of goodness! Bad dog! Bad dog!" 

- The Tick. 
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Subject: 


Sent: 
To: 

Cc: 


From: 


wampler (Kurt Warn pier) 

Tuesday, August 01, 1995 12:27 AM 

albers; geert; hopper; tbr; torn; vanthof 

tau 

Re: euterpe tapout? here we go... 


Tom writes: 


>I just got buttonholed by Jack, Al, and Anh for an impromptu meeting 
>about euterpe tapeout, given the edict that we must have euterpe 
>silicon by Dec 31. I explained that euterpe, as it exists now, does 
>not meet the "compromise 1 design rule set developed last week, and I 
>estimated 3 months of layout work before it could be made to do so. 

Not to mention the very real risk that Euterpe would no longer route 
to completion with the compromise rules' larger vias. 

>Given this, Al and Anh agreed that the best move is to tape out the 
>baseplate layers (currently defined as 010-14 0 -- all but metals, SDEC, 
>and silicide) ASAP in their current form, and pressed me for an 
>estimate of how soon this could happen. I made the possibly rash 
> statement that I thought we might be able to tapeout the baseplate on 
>Aug 14. (Jack mentioned some 1- or 2-udr well-well and well-nactive 
>spacing violations, to which Al said "waive them') 

Will there be any changes needed on the poly layer to comply with 
the new SDEC ISO rules? 

>After some argument, we settled on Sep 1 as the target date to tape out 
>the layers up through Ml (plus any more metals we can get out by then) , 
>with the remaining metal layers taping out promptly thereafter. 

This is "ship physical tapes on Sep 1" or "commence fracture on Sep 1"? 
I don't see a problem with shipping tapes on Sep 1 as long as we 
start the fracture by Aug. 28. We'll need 2-3 days to compute layers 
010-140, and a little time to review post -fracture DRC flags & write 
the tapes. 

> [snip] 

>The impression I have now is that taping out euterpe is our highest 
>priority, but I dunno -- the highest priority seems to change several 
>times a week as far as I can tell. 

Whether we tape out euterpe, pollux, or mnemo, the drill is pretty 
similar, and once we've ironed out all of the synthesis details 
for one of them, the others ought to follow pretty much the same 
formula (except for any midstream revisions we make in response to 
Sisyphus 2 characterization) . 

>Are we having fun yet? 

Can't wait to get ported onto that Alpha box! 


- Kurt 
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Sent: 

To: 

Cc: 


Subject: 


From: 


tbr 

Tuesday, August 01, 1995 12:17 AM 
vanthof (vant) 

albers (Daniel Albers); geert (Geert Rosseel); hopper (Mark Hofmann); Tom Laidig [tau]; 
vanthof (Dave Van't Hof); warn pier (Kurt Wampler) 
Re: euterpe tapout? here we go... 


vant wrote (on Mon Jul 31) : 


> 


. >After some argument , we settled on Sep 1 as the target date to tape out 
>the layers up through Ml (plus any more metals we can get out by then) , 
>with the remaining metal layers taping out promptly thereafter. 

According to what rules? If we are going to tape out euterpe to the 
current rule set, then I think we can do upto metall. if we are to meet 
the compromised set, then your estimate of 3 months is more accurate. 

Plan should be to get it clean per the current rules and get going with that version so we 
have the soonest possible mask set . It may make sense to follow that up with a revised 
version which also meets a subset of the compromise rules if we can get some guidance on 
the most important. ie do the 10% of the work that gets the 90% benefit. 


Tim 
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